微服务个人总结

什么是微服务

微服务其实说的是一种架构，是一种由多个微型服务组成的一种架构方式，其中对这些微型服务的要求是:

1. 高度可维护和可测试；
2. 松耦合；
3. 独立部署；
4. 根据业务组织调整；
5. 是由专门的团队负责；

如下图所示：

与传统的单体架构(Monolithic Architecture)的对比

传统服务部署的特点：
把所有的功能和模块集中到一个应用中，然后将其按照war的方式部署在servlet容器中(比如tomcat)，提供了所有对外的接口和功能；
优点：

1. 易开发（当前的工具都是为了开发单个应用而设计，方便开发人员开发和测试）；
2. 易部署（只要将程序打包成为war，部署到容器中即可）；
3. 易扩展（只要多启动几个容器实例即可）；

但是上面说的有点仅限于应用程序体量小时存在，当应用的体量大幅度提升后上面的优点就变成了缺点:

1. 难开发：
   1. 当体量变大后，开发人员需要熟悉所有的业务逻辑，尤其对新人而言；
   2. 当前的开发工具会随着应用变大而变慢，影响开发效率；
2. 难部署：
   1. 容器的启动时间会随其应用的体量增大而增大；
   2. 持续交付和部署会很难，因为频繁的部署大应用可能会中断其中的任务，比如使用了Quartz job等；
3. 难扩展：
   1. 所有的扩展实例都是需要访问所有的资源(IO/DB)等，不能根据数据量来进行调整，比如有的模块是消耗CPU的，有的模式是消耗内存的；
   2. 不能很好的形成自己专门的技术栈，所有人需要学习所有的逻辑，而不是每个模块有专人负责；
   3. 不能很好的进行技术的更新；

微服务的优点:

1. 方便持续交付和持续部署；
   1. 改善可维护性-小型服务都容易理解和修改；
   2. 每个微服务可以独立部署；
   3. 团队之间更独立；
2. 每个微服务都相对较小：
   1. 易于开发人员理解和开发；
   2. 开发工具更快更高效；
   3. 服务启动更快，更快部署；
3. 改善故障隔离-如果其中一个微服务故障，其他微服务仍可继续提供服务；
4. 方便更新技术栈-可以保证最小影响来使用更新的技术栈或版本；

微服务的缺点：
与传统一样，在不同的情形下优点也是缺点，如果在小体量的团队和应用面前，微服务的优点就是缺点了：

1. 不方便开发
   1. 联调时需要本地启动多个应用；
   2. 需要实现服务间的通信及处理部分异常情形；
   3. 增大测试成本；
2. 不方便部署（小体量改版往往是整体模块都受影响，所以需要部署多个服务）；
3. 资源浪费（有的小模块对资源需求很小，但如果以服务方式启动就会浪费）；

使用微服务会涉及到模式

下面的图是使用微服务开发可能会涉及到模式:

如果要使用微服务架构，那么会涉及到很多问题，为了解决这些问题及连锁问题，就出现了与问题对应的解决模式，一共可以分为14类。下面的模式其实是一些通用的模式：

1. 应用架构-Application architecture patterns：
   1. Monolithic architecture - 单体架构；
   2. Microservice architecture - 微服务架构；
      这个解决模式是总体的，下面的解决模式是基于应用架构选择了微服务架构的前提下；
2. Decomposition - 分解
   1. decompose by business capability - 按业务能力分解 - 可以理解为按照公司部门进行拆分-康威定理;
   2. decompose by subdomain - 按子域分解 - 可以理解为按照领域(或者说按照信息处理流程)进行拆分;
      遵循的原理：参考面向对象设计(OOD)中的单一职责原则(Single Responsibility Principle-SRP)和公共闭合原则(Common Closure Design-CCP)进行拆分;
3. Data management - 数据管理
   1. Database per Service - 数据库服务隔离-dps；
      如果服务之间采用各自独立数据库，那么会有数据一致性的问题；为了解决服务间的事物问题和多表联查的查询问题，分别引入了：
      1. Saga模式 - 通过分解为多个本地事物来解决服务间的数据一致性，
         实现方式有两种方式：
         • 编制（Orchestration-管弦乐）-通过引入一个中心控制者来协调工作；
         • 编排（Choreography-舞蹈术）-通过定义一些列通用规则达到相互之间的协同工作；
      2. API Composition-通过将不同服务的数据查询汇总到内存后，在内存中进行join来解决；
      3. Command Query Responsibility Segregation (CQRS)- 通过定义一个只读的视图数据库来实现多表联查，视图数据库中的数据通过
         订阅目标数据所属服务的Domain Event-域事件来实现数据的更新，
         而域事件是通过将业务逻辑封装为一系列的DDD（Domain Driven Design）集合，当业务逻辑发生新增或者修改等变动时通过发布domain events
         来告知其他订阅的服务；而Event sourcing事件收集通过将事件
         序列化存储（类似于mq）来达到可以发布一致性的消息的目的。
   2. Shared database（共享数据库）sd;
4. Transactional messaging - 事务性消息
   1. Transactional outbox - 事务性发件箱 -
      通过在关系型数据库中新建一张outbox表来实现，将outbox表中数据插入更新的操作放在本地的事物中即可；
   2. Transaction log tail - 事物更新日志 -
      与事务性消息类似，另建一张表，只不过表中存储的是数据库的最新的事务日志，再另起一个线程将更新后的数据发送给消息中继（Message Relay），
      最后发送给消息代理（Message Broker）。
   3. Polling publisher- 与outbox的区别？
5. Communication Style - 通信模式
   1. RPI - 远程过程调用 - 常用的方式有：
      1. REST: 最常见的就是http服务
      2. RPC：gRPC
      3. Apache Thrift
   2. Messaging - 消息，比如kafka、rocketMQ等；
   3. Domain-Specific Protocol - 特定领域协议 - 比如邮件协议SMTP和IMAP;
6. Reliability - 可靠性
   1. Circuit Break - 熔断 -
      为了防止服务不可用导致雪崩效应而设立的一种保护机制，主要是通过代理调用的服务，统计调用服务的情况，如果失败率达到一定阈值，则开启熔断一定时间，
      熔断时间过后会开启半开(half-open)状态，半开状态下如果调用的服务正常则关闭熔断，否则转为全熔断状态一定时间；
7. Service discovery - 服务发现
   1. Client-side discovery - 客户端侧 -
      由调用方直接调用Service Registry获取服务方的地址；
   2. Server-side discovery - 服务端侧 -
      调用方调用一个路由，路由再调用Service Registry服务获取地址
   3. Service registry - 注册服务 -
      其实就是一个数据库，库中维护各个服务可用的地址，但Service Registry本身的地址是固定的。服务注册又可以分为以下两种:
      1. Self registration - 自注册 -
         服务启动时自己向注册服务注册，服务关闭时自己向注册服务解注册；
         1. An AWS Elastic Load Balancer (ELB)；
         2. Aliyun Service Load Balancer (SLB);
      2. 3rd party registration - 第三方注册 -
         依赖第三方注册商，当服务启动时，注册商向注册服务注册，当服务关闭时，注册商向注册服务解注册。
         1. Netflix Prana - a “side car” application that runs along side a non-JVM application and registers the application with Eureka.
         2. AWS Autoscaling Groups automatically (un)registers EC2 instances with Elastic Load Balancer
         3. Joyent’s Container buddy runs in a Docker container as the parent process for the service and registers it with the registry
         4. Registrator - registers and unregisters Docker containers with various service registries
         5. Clustering frameworks such as Kubernetes and Marathon (un)register service instances with the built-in/implicit registry