微服务基础

一，什么是微服务

在这里插入图片描述

在这里插入图片描述

什么是服务化？

• 把传统的单击应用中的本地方法调用，改造成通过RPC,HTTP产生的远程方法调用

• 把模块从单体应用中拆分出来，独立成一个服务部署

• 用户模块就可以独立开发，测试，上线和运维，可以交由专门的团队来做，与主模块不耦合
  

  

  在这里插入图片描述
  
  什么是微服务？

• 一种架构风格

• 开发单个应用作为一系列小型服务的套件，其中每个服务都运行在自己的进程中，并且通过轻量级的机制实现彼此间的通信，这通常是http资源API

• 这些服务是围绕着业务功能构建的，并且可以通过完全自动化的部署机制进行独立部署

• 这些服务的集中式管理做到了最小化（比如docker相关技术），每一种服务都可以通过不同的编程语言进行编写，并且可以使用不同的数据存储技术。

二，微服务的特点

1. 组件以服务的形式来提供：微服务面向服务，提倡以独立部署的服务来作为一个个组件，而不是提供包括类库，本地方法之间的调用的形式，这样我们需要明确组件间的接口和通信协议

2. 产品不是项目（传统开发中我们一般把它当做项目，做完了交给维护部门去维护即可。微服务不是这样的，需要对整个生命周期去负责，这样也导致不方便进行外包，因为涉及到的人力会非常多）

3. 轻量级通信，独立进程（会更加倾向于restful，http，rpc，或愿意采用轻量级的消息队列，比如rabbitmq，而不是更加复杂的协议）

4. 分散治理，去中心化治理（微服务会把单体框架的组件拆成不同的服务，构建时候是比较分散的，意味着责任下放，不同团队需要对自己的项目负责）

5. 容错性设计（现在每个服务是独立的，所以对于每一个模块，都要提供日常的故障检测。使用微服务一方面整体的容错性提高了，因为一个模块的故障不会影响全部，但是对个人而言压力更大了，因为一个模块的错误可能会影响其他模块）

6. 会带来团队组织架构的调整（从横向编程斜向）
   

   

   在这里插入图片描述
   
   结论：

微服务系统需要满足一系列条件和原则，但是并不代表你使用了某个技术或框架就是微服务了。微服务可用模块非常多，我们应该按照项目需要进行选取

三，微服务的优缺点

优点：

1）服务简单，便于学习和上手，相对易于维护

2）独立部署，灵活扩展

在这里插入图片描述

3）技术栈丰富，比如语言，开发工具，中间件等技术（非常有利于去引入新技术，可以在某一个小模块先进行使用，等成熟之后再推广到其他模块）

缺点：

1）运维成本过高

2）接口可能不匹配

3）代码可能重复

4）架构复杂度提高

不同复杂度情况下，单体应用和微服务的优劣势
横轴复杂度，数轴生产率，绿色是单体应用，蓝色是微服务架构

在这里插入图片描述

四，微服务的两大门派

在这里插入图片描述

在这里插入图片描述

ps：无只是表示dubbo没有，但是它可以使用三方插件来实现

image

在这里插入图片描述

总结和选型建议：

• dubbo诞生于阿里系，而且这个也广泛应用，但是因为诞生之初是为阿里的业务服务的，所以各个组件不太全面，增加了使用难度。spring cloud是spring家族的，专注企业级微服务领域，而且迭代快，组件全，开发起来非常简单便捷。dubbo再次之前有很长时间的停止维护，但是现在正常更新了

• 比喻：组装电脑，品牌机

• 如果想稳定可靠，就选择spring cloud，如果想了解dobbo，或者觉得文档全，就选择dubbo，需要根据自身的研发水平和所处阶段选择

五，微服务的拆分

什么时候进行服务化拆分：

1. 第一阶段的主要目标是快速开发和验证想法（通常第一阶段都打包在一起进行开发运维，这是最高效也最节省成本的方式）

2. 进一步增加更多的新特性来吸引更多的目标用户

3. 同时进行开发的人员超过10人，这个时候就该考虑进行服务化拆分了

不适合拆分的情况：

1. 小团队，技术基础较为薄弱

2. 流量不高，压力小，业务变化也不大（比如企业内部的管理系统）

3. 对延迟很敏感的低延迟高并发系统

微服务拆分的两种方式：

1. 纵向拆分：按照业务维度去拆分，关联程度紧的就拆分成一个微服务，功能比较独立的拆分成一个微服务。比如社交app，可以对评论，消息，个人主页独立拆分

2. 横向拆分：按照公共领域去拆分，比如社交app，评论，消息，个人主页都需要用到用户模块，如果纵向拆分里这几个模块都分别实现用户模块，成本就太高了，可以把用户服务作为横向拆分出来，并且把这个功能提供给各个模块，这样用户服务复用性就很高

3. 结合业务综合分析，一般需要同时采用横向和纵向两种，无论是采用横向还是纵向拆分，不一定是拆分的越细越好，过细会让服务数量膨胀，变得难以管理，要结合实际进行拆分，建议每个开发负责的服务不超过3个。
   六，服务扩展

   
   
   

   在这里插入图片描述

• x轴-水平复制：把系统作为一个整体，直接重新部署几套，然后前面加几个负载均衡器解决问题（效果部署特别好，资源存在浪费）

• y轴-功能解耦：微服务拆解，效率比x轴高

• z轴-数据分区：在系统更大之后，数据库是需要分区独立的，可以按照不同属性值进行数据拆分，独立提供资源，提高系统的可用性和性能

自动按需扩展：

• 根据cpu负载程度，特定时间（比如周末），消息中间件的队列长度，业务具体规则，预测等来决定是否扩展

• 自动分配一个新的服务实例，提高可用性

• 提高了可伸缩性（双11之后，自动减少服务器）

• 具有最佳使用率，节约成本

六，微服务重要模块

1. 服务描述：说明是http服务还是其他类型的，接口什么样子，返回什么内容

2. 注册中心：不注册消费者就不知道去哪里找到

3. 服务框架：注册好后还需要解决以下问题，比如采用什么协议，传输类型等，服务框架就会对此进行统一

4. 负载均衡

5. 熔断与降级：服务多了以后，如果某一个服务发生故障，那还有兜底策略

6. 网关：当服务多了以后，需要统一网关，然后由网关进行下一步的分发，还有进行统一转换，权限校验，过滤等