一，什么是微服务
什么是服务化？
把传统的单击应用中的本地方法调用，改造成通过RPC,HTTP产生的远程方法调用
把模块从单体应用中拆分出来，独立成一个服务部署
-
用户模块就可以独立开发，测试，上线和运维，可以交由专门的团队来做，与主模块不耦合
在这里插入图片描述
什么是微服务？ 一种架构风格
开发单个应用作为一系列小型服务的套件，其中每个服务都运行在自己的进程中，并且通过轻量级的机制实现彼此间的通信，这通常是http资源API
这些服务是围绕着业务功能构建的，并且可以通过完全自动化的部署机制进行独立部署
这些服务的集中式管理做到了最小化（比如docker相关技术），每一种服务都可以通过不同的编程语言进行编写，并且可以使用不同的数据存储技术。
二，微服务的特点
组件以服务的形式来提供：微服务面向服务，提倡以独立部署的服务来作为一个个组件，而不是提供包括类库，本地方法之间的调用的形式，这样我们需要明确组件间的接口和通信协议
产品不是项目（传统开发中我们一般把它当做项目，做完了交给维护部门去维护即可。微服务不是这样的，需要对整个生命周期去负责，这样也导致不方便进行外包，因为涉及到的人力会非常多）
轻量级通信，独立进程（会更加倾向于restful，http，rpc，或愿意采用轻量级的消息队列，比如rabbitmq，而不是更加复杂的协议）
分散治理，去中心化治理（微服务会把单体框架的组件拆成不同的服务，构建时候是比较分散的，意味着责任下放，不同团队需要对自己的项目负责）
容错性设计（现在每个服务是独立的，所以对于每一个模块，都要提供日常的故障检测。使用微服务一方面整体的容错性提高了，因为一个模块的故障不会影响全部，但是对个人而言压力更大了，因为一个模块的错误可能会影响其他模块）
-
会带来团队组织架构的调整（从横向编程斜向）
在这里插入图片描述
结论：
微服务系统需要满足一系列条件和原则，但是并不代表你使用了某个技术或框架就是微服务了。微服务可用模块非常多，我们应该按照项目需要进行选取
三，微服务的优缺点
优点：
1）服务简单，便于学习和上手，相对易于维护
2）独立部署，灵活扩展
3）技术栈丰富，比如语言，开发工具，中间件等技术（非常有利于去引入新技术，可以在某一个小模块先进行使用，等成熟之后再推广到其他模块）
缺点：
1）运维成本过高
2）接口可能不匹配
3）代码可能重复
4）架构复杂度提高
不同复杂度情况下，单体应用和微服务的优劣势
横轴复杂度，数轴生产率，绿色是单体应用，蓝色是微服务架构
四，微服务的两大门派
ps：无只是表示dubbo没有，但是它可以使用三方插件来实现
总结和选型建议：
dubbo诞生于阿里系，而且这个也广泛应用，但是因为诞生之初是为阿里的业务服务的，所以各个组件不太全面，增加了使用难度。spring cloud是spring家族的，专注企业级微服务领域，而且迭代快，组件全，开发起来非常简单便捷。dubbo再次之前有很长时间的停止维护，但是现在正常更新了
比喻：组装电脑，品牌机
如果想稳定可靠，就选择spring cloud，如果想了解dobbo，或者觉得文档全，就选择dubbo，需要根据自身的研发水平和所处阶段选择
五，微服务的拆分
什么时候进行服务化拆分：
第一阶段的主要目标是快速开发和验证想法（通常第一阶段都打包在一起进行开发运维，这是最高效也最节省成本的方式）
进一步增加更多的新特性来吸引更多的目标用户
同时进行开发的人员超过10人，这个时候就该考虑进行服务化拆分了
不适合拆分的情况：
小团队，技术基础较为薄弱
流量不高，压力小，业务变化也不大（比如企业内部的管理系统）
对延迟很敏感的低延迟高并发系统
微服务拆分的两种方式：
纵向拆分：按照业务维度去拆分，关联程度紧的就拆分成一个微服务，功能比较独立的拆分成一个微服务。比如社交app，可以对评论，消息，个人主页独立拆分
横向拆分：按照公共领域去拆分，比如社交app，评论，消息，个人主页都需要用到用户模块，如果纵向拆分里这几个模块都分别实现用户模块，成本就太高了，可以把用户服务作为横向拆分出来，并且把这个功能提供给各个模块，这样用户服务复用性就很高
-
结合业务综合分析，一般需要同时采用横向和纵向两种，无论是采用横向还是纵向拆分，不一定是拆分的越细越好，过细会让服务数量膨胀，变得难以管理，要结合实际进行拆分，建议每个开发负责的服务不超过3个。
六，服务扩展
在这里插入图片描述
x轴-水平复制：把系统作为一个整体，直接重新部署几套，然后前面加几个负载均衡器解决问题（效果部署特别好，资源存在浪费）
y轴-功能解耦：微服务拆解，效率比x轴高
z轴-数据分区：在系统更大之后，数据库是需要分区独立的，可以按照不同属性值进行数据拆分，独立提供资源，提高系统的可用性和性能
自动按需扩展：
根据cpu负载程度，特定时间（比如周末），消息中间件的队列长度，业务具体规则，预测等来决定是否扩展
自动分配一个新的服务实例，提高可用性
提高了可伸缩性（双11之后，自动减少服务器）
具有最佳使用率，节约成本
六，微服务重要模块
服务描述：说明是http服务还是其他类型的，接口什么样子，返回什么内容
注册中心：不注册消费者就不知道去哪里找到
服务框架：注册好后还需要解决以下问题，比如采用什么协议，传输类型等，服务框架就会对此进行统一
负载均衡
熔断与降级：服务多了以后，如果某一个服务发生故障，那还有兜底策略
网关：当服务多了以后，需要统一网关，然后由网关进行下一步的分发，还有进行统一转换，权限校验，过滤等
