微服务概念学习笔记

        Martin Flower曾经说过，微服务的架构风格，就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制独立部署。这些服务可以使用不同的编程语言，以及不同的存储技术，以保证最低限度的集中式管理。

特点：

1. 按业务划分为一个独立运行的程序，即服务单元。
2. 服务之间通过HTTP协议相互通信。
3. 自动化部署。
4. 可以用不同的编程语言。
5. 可以用不同的存储技术。
6. 服务集中化管理。
7. 微服务是一个分布式系统。

阐述：

1. 微服务单元按业务来划分：这些微服务单元是高度组件化的模块，提供了稳定的边界，服务与服务之间没有任何的耦合，有非常好的扩展性和复用性。
2. 微服务通过HTTP来互相通信。
3. 微服务的数据库独立。一个典型的微服务架构就是每个微服务都有自己的数据库，数据库之间没有任何的联系。优点：单业务的数据量少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。
4. 微服务的自动化部署，（DOCKER,Jenkins）
5. 分布式架构
6. 熔断机制（Hystrix组件的Circuit Breaker）

优势：

1. 将一个复杂的服务分解成若干小的服务，每个业务拆分成一个服务，服务的边界明确，将复杂问题简单化。服务按照业务拆分，编码也是按照业务拆分， 代码的可读性和可扩展性增加。新人加入团队，不需要了解所有的业务代码，只需要了解她所接管的服务的代码，降低学习时间成本。
2. 由于微服务系统是分布式系统，服务与服务之间没有任何的耦合，随着业务的增加，可以根据业务再拆分业务，具有极强的横向扩展能力。随着应用的用户量的增加，并发量增加，可以将微服务集群化部署， 增加系统的负载能力。
3. 服务与服务之间通过HTTP网络通信协议来通信，单个微服务内部高度耦合，服务与服务之间完全独立，无耦合。微服务可以采用任何的开发语言和开发技术来实现。
4. 由于微服务系统是按照业务进行拆分的，并且有坚实的服务边界，所以重写某个服务相当于重写某个业务的代码，相对于重写单体应用来说，简单不少。
5. 微服务的每一个服务单元都是独立部署的，即独立运行在某个进程里。微服务的修改和部署对其他服务没有影响。
6. 微服务在CAP（Consistency，Availability，Partition-tolerance）理论中采用的是AP架构，具有高可用和分区容错的特点。

不足

1. 微服务的复杂度
2. 分布式事务（如何保持数据的一致性？两阶段提交）
3. 服务的划分（领域驱动设计DDD）
4. 服务的部署 

 两阶段提交：网购买手机，需要在个人账户中扣除2000元钱，在手机库存中将手机库存数量减1，当然需要在卖方账户中增加2000元钱。

        在微服务架构中，账户是一个服务，而商品是一个服务，这时不能用数据库自带的事务，因为这两个数据表不在一个数据库中，因此常常用到两阶段提交。

        第一阶段，service-account发起一个分布式事务，交给事务协调器TC处理，事务协调器TC向所有参与事务的节点发送处理事务操作的准备操作，所有的参与节点执行准备操作，将Undo和Redo信息写进日志，并向事务管理器返回准备操作是否成功。

        第二阶段，事务管理器收集所有所有节点的准备操作是否成功，如果都成功，则通知所有节点执行提交操作，如果有一个失败，则执行回滚操作。

1.微服务应该具备的特点

• 按业务来划分，单个服务代码量小，业务单一，易于维护。
• 每个微服务都有自己独立的组件，例如数据库，缓存等，且运行在独立进程中。
• 微服务之间的通信通过HTTP协议或者消息组件，且具有容错能力。
• 微服务有一套服务治理的解决方案，服务之间不耦合，可以随时加入或者剔除服务。
• 单个微服务能够集群化部署，并且具有负载均衡的能力。
• 整个微服务应该有一个完整的安全机制，包括用户验证，资源验证，权限保护等。
• 整个微服务系统有链路追踪的能力。
• 有一套完整的实时日志系统。

2.微服务主要功能介绍：

2.1 服务的注册与发现： 为了能够方便查看每个微服务实例的健康状态，该系统需要服务注册中心来统一管理微服务实例。服务注册是指向服务注册中心注册一个服务实例。服务提供者将自己的服务信息（服务名，ip地址等）告知服务注册中心。服务发现是指当服务消费者需要消费另外一个服务时，服务注册中心能够告知服务消费者它所要消费服务的实例信息（服务名，ip地址等）。通况下，一个服务既是服务提供者，又是服务消费者，一般使用HTTP协议或是轻量级组件来完成服务消费。

 2.2 服务的负载均衡

        由于服务之间一般都是通过HTTP协议完成相互调用，但是网络往往具有不可靠性，为了保证服务的高可用（High Availability），服务单元往往集群化部署。可是如果将的服务提供者进行集群化部署，那么服务消费者该调用哪个服务提供者的实例呢？这个时候就用到了负载均衡。

        服务的负载均衡的流行做法：所有服务都向服务注册中心注册，服务的注册中心持有每个服务的应用名和ip地址等相关信息，同时每个服务也会获取所有服务注册列表信息。服务消费者集成负载均衡组件，该组件会向服务消费者获取服务注册列表信息，并每隔一段时间重新刷新获取该列表，当服务消费者消费服务时，负载均衡组件获取服务消费者所有实例的注册信息，并通过一定的负载均衡策略（由开发者配置），选择一个服务提供者的实例，向该实例进行服务消费，这样就实现了负载均衡。

        服务注册中心不但需要定时接收每个服务的心跳（检测服务是否可用），而且每个服务会定期获取服务注册列表信息，当服务实例很多时，服务注册中心承载了非常大的负载，由于服务注册中心在微服务系统中起到了至关重要的作用，所以必须实现高可用。一般的做法是将服务注册中心集群化，每个服务注册中心数据实时同步。

 2.3 服务的容错

        微服务落地到实际项目中，服务的数量往往非常多，服务之间的相互依赖性也是错综复杂的，一个网络请求通常要调用多个服务才能完成。如果一个服务不可用，例如网络延迟或故障，会影响到依赖于这个不可用的服务的其他服务。如下所示，一个微服务系统有许多服务，当服务F因为某些原因导致了服务的不可用，来自于用户的网络请求需要调用服务F，由于服务F无响应，用户的请求处于阻塞状态，在高并发的场景下，短时间会导致服务器看的线程资源消耗殆尽，另外依赖于服务F的其他服务，也会等待服务F的响应，处于阻塞状态，导致这些服务的线程资源消耗殆尽，进而导致他们不可用，以及依赖于他们的服务不可用，最后导致整个系统处于瘫痪状态，也就是雪崩效应。

        为了解决分布式系统的雪崩效应，分布式系统引进了熔断器机制。熔断器（Circuit Breaker）

其作用是当电路中出现故障时立即切断电路，起到保护电路的作用。当一个服务处理用户失败请求的次数在一定时间内小于设定的阀值时，熔断器处于关闭状态，服务正常，当服务处理用户请求失败次数超过设定的阀值时，打开熔断器，这时所有请求会执行快速失败，不执行业务逻辑。当熔断器处于打开状态时，一段时间会处于半打开状态，并执行一定数量的请求，剩余的请求会执行快速失败，若执行的请求失败了，会继续打开熔断器，若执行成功，会关闭熔断器。

熔断器（Netflix的Hystrix）的意义：

• 将资源进行隔离，如果某个服务里的某个api接口发生了故障，只会隔离该api接口，不会影响到其他api接口，被隔离的api接口会执行快速失败的逻辑，不会等待，请求不会阻塞。如果不进行隔离，请求会一直处于阻塞状态，直到超时。如果有大量请求同时涌入，都处于阻塞的状态，服务器的线程资源会被迅速消耗完。
• 服务降级。当服务处于正常状态时，大量请求短时间内同时涌入，超过了服务的处理能力，这时熔断器会被打开，将服务降级，以免服务器因负载过高而出现故障。
• 自我修复能力。当因某个微小的故障，例如网络服务商的问题，导致网络在短时间内不可用，熔断器被打开，如果不能自我监控，自我检测和自我修复，那么需要开发人员手动的关闭熔断器，显然会增加开发人员的工作量。

 2.4 服务的网关

        微服务系统通过将以API接口的形式暴露给外界来提供服务。在微服务系统中，API接口资源通常采用服务网关（也称API网关）同一暴露，内部服务不直接提供API资源的暴露。API网关有一定的请求转发的作用，另外他可能需要负责一定的安全验证，例如判断某个请求是否合法，该请求对某一资源是否有操作权限等。通况下，网关以集群方式存在。在服务网关层之前，有可能需要加上负载均衡层，通常为Nginx双机热备，通过一定的路由策略，将请求转发到网关层。到达网关层后，经过一系列的用户身份验证，权限判断，最终转发到具体的任务，具体的任务经过一系列的逻辑运算和数据操作，最终将结果返回给用户。

网关层的意义：

• 网关将所有服务的api接口资源同一聚合，对外同一暴露，外界系统调用的API接口都是网关对外暴露的API接口。
• 网关可以做一些用户身份认证，权限认证，防止非法请求操作API接口，对内部服务起到保护作用。
• 网关可以实现监控功能，实时日志输出，对请求进行记录。
• 网关可以用来做流量监控， 在高流量情况下，对服务进行降级。
• API接口从内部服务中分离出来，方便做测试。

 2.5 服务配置的统一管理

        在实际开发过程中，每个服务都有大量的配置文件。

•  首先，Config Server(配置服务)读取配置文件仓库的配置信息，其中配置文件仓库可以存放在配置服务的本地仓库，也可以放在远程的Git仓库。
• 配置服务启动之后，读取文件的配置信息，读取完成的配置信息存放在配置服务的内存中。
• 当启动服务A,B时，由于服务A、B指定了向配置服务读取配置信息，服务A、B向配置服务读取配置信息。
• 当服务配置信息需要修改且修改完成后，向配置服务发送POST请求进行刷新，这时服务A,B会向配置服务重写读取配置文件。

• 

2.6 服务的链路追踪

 总结：微服务的设计是渐进式的，是随着业务的发展而发展的。