微服务

为什么需要微服务？

借用一张图来说明。图中横轴是复杂度，纵轴是生产效率。从生产效率的角度来讲，在两条曲线的交叉点之前，单体架构是占优势的，过了交叉点之后，单体架构的生产效率将大幅度下降。随着单体应用的复杂度增加，开发效率必然下降，这时微服务化就显得非常重要
什么是微服务
微服务是一种架构模式，它提倡将单一应用划分成一组小的服务 ，每个服务运行在其独立的进程中，服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTful API），每个服务都是围绕着具体业务进行构建，并且能够被独立部署到生产环境、类生产环境。
微服务是一种将单个应用以许多微小服务所组成的服务套件的形式来构建软件的方法，每个微服务拥有自己的轻量级数据处理模块以及通信机制（通常是HTTP API）。微服务围绕业务能力和各种独立的自动化部署机制构建而来，由于微服务需要极少的集中管理，因此各个服务可使用不同的编程语言以及存储技术。
微服务的特征
每个微服务都是小而专注。（小不是绝对的，相对一个大而完整的服务，微服务化更倾向于小一些的单一服务。即 提出每个服务只专注于做一件事情，并且把它做好）
每个微服务都是按照业务能力构建的
每个微服务都是可以独立部署的，并运行在独立的进程中 （注：并不是只能有一个进程）
每个微服务都有自己的持久化存储，不再提倡多个服务共享一个大而全的持久化存储。
微服务间采用轻量级的通信机制相互沟通
请求响应类，通常是基于HTTP协议的RESTFull API
生产消费类，通常采用轻量级的消息队列
微服务的优点：
组件化： 每个微服务与其他微服务高度解耦，自包含，仅通过接口或者消息和其他服务进行通信。
去中心化： 不同的微服务可以使用不同的技术栈、语言、框架、存储，真正做到用最适合的技术解决最适合的问题。微服务提倡每个服务自己管理自己的数据库，实现数据管理的去中心化，避免共享的数据库结构变更而影响多个服务。
高扩展性：在PAAS平台下的帮助下 ，每个微服务可以根据实时资源需求自动进行动态的扩展。由于微服务粒度相对较小，因此在动态扩缩的时候，比单体应用更节约资源。
快速响应：由于微服务粒度相对比较小，因此更易于变更以敏捷的快速响应需求和市场的变化。
组织更高校：微服务提倡采用全智能的微团队来进行负责，这种团队小而精悍，沟通效率高，战斗力强。由于微团队对每个微服务的全生命周期进行负责，团队与最终用户之间的距离很近，更易于微服务本身进行改进。
微服务的缺点：
提升了系统复杂度：微服务之间的连接更加复杂，网络通讯部可靠和性能消耗，协议匹配，接口对接和转换，版本协作，服务注册、发现、编排和调度，分布式业务和数据一致性等等，这些都是微服务需要面临的复杂问题，而单体应用根本没有这些问题。必须要有一个强大的PAAS平台作为基础来降低系统的复杂度。
增加了运维负担：必须额外提供强大的监控设施来监控每个微服务的健康状态；由于服务众多，调用路径负责，导致排查问题效率会减低，平均修复时长会增加；对运维人员要求很高，要求运维人员进入开放过程，运维人员和开发人员一起接收业务需求，运维人员负责输出运维相关的非功能需求。
静态检查复杂：无法通过类似于编译的方法提前发现接口错误
事务一致性复杂：微服务本质上是一种分布式架构 ，分布式事务的一致性需要特别机制来保证；
单体应用优缺点
优点
 易于开发: 开发简单直接，集中式管理
 易于测试: 没有耦合，一次交付一次测试
 易于部署: 功能都在本地，没有分布式的管理开销和调用开销
缺点
 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
 代码维护难：代码功能耦合在一起，新人不知道何从下手
 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
 扩展性不够：无法满足高并发情况下的业务需求

如何实施微服务
技术：
单体优先：从单体架构开始，通过演进式设计逐渐重构到微服务架构；
按需演进：软件架构的基本规律：架构是通过解决当前的需求和痛点而演进的，无法根据每月出现的问题和痛点而进行设计
组织：
康威定律：设计系统的组织，其生产的设计等价于这些组织间的沟通结构。一个产品或者系统的设计（架构）必然受到其生产组织自身交流沟通结构的制约。所以，要实施好微服务，企业组织机构必须要其他对齐。
微团队：微服务提倡anywhere能力进行划分，而不是技术能力，提倡通过一个小而完整的跨职能团队来负责（包含开发人员、业务分析师、ＤBA，运维人员、测试人员等）
鼓励创新：必须创建一个信任并鼓励创新的环境，抛弃“宁可不作为，也不能犯错”的文化
基础实施
持续集成和交付:自动化构建，自动化测试（UI/集成/单元、回归），自动化部署，自动化性能测试，自动化安全扫描等等
实时监控：必须要有强大的监控设施来监控每个微服务的监控状态；监控包含服务可用状态，请求流量，调用链路， 容错机制等待
日志管理： 必须要有统一的日志管理设施来帮助理解珍格格复杂系统的行为；
PAAS平台：必须要有一个强大的PAAS平台作为基础来减低系统的复杂度
客户端到微服务直接通信

一个客户端可以直接给多个微服务中的任意一个发起请求，每一个微服务都会有一个对外服务端，这个URL可能会映射到微服务的负载均衡上，他再转发请求到具体节点上。
如果客户端代码非常复杂，每个客户端的需求量与每个微服务暴露的细粒度API数量不匹配。那么将采用什么样形式的通信才适合呢？
采用一个API网关。

API GateWay是一个服务器，拥有对外的IP，是外部进入系统的唯一入口。API GateWay
作为系统的唯一入口，API网关对外部服务，提供反向路由，安全认证，限流，容错等能力。
常用的API网关有：zuul、Spring Cloud GateWay、Edge Service;

服务间是如何通信的？

在微服务架构中，一般每一个服务都是有多个服务实例来做负载均衡。每个服务实例的网络地址都是动态分配的，而且因为扩展、失效和升级等需求，服务实例会经常改变，也可以应对临时访问压力增加新的服务节点。这种情况下服务之间如何相互感知，服务如何管理？这就是服务发现的功能范畴了。

服务发现主要提供如下功能：
服务注册：当服务上线时，服务提供者将自己的服务信息注册到服务注册模块，并通过心跳维持长连接，实时更新连接信息。
服务发现：服务调用者通过服务注册模块寻址，根据可定制算法找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，服务注册模块会发通知给服务客户端。

服务注册有两种方式：自注册模式和第三方注册模式；

自注册方式：服务实例负责在服务注册中心注册和注销。另外，如果需要，一个服务实例也要发送心跳来保证注册信息不会超时。
Netflix OSS Eureka client就是使用这种方式进行服务注册的。Eureka的客户端处理了服务注册和注销的所有工作。
Self-Registration方式的优缺点：一个明显的优点就是，非常简单，不需要任何其它辅助组件。而缺点也是比较明显的，使得各个服务和注册中心的耦合度比较高。服务的不同语言的客户端都得实现注册和注销的逻辑。

第三方注册方式

第三方服务管理器负责注册。服务管理器通过查询环境不是或者订阅事件来跟踪运行服务的改变。当管理器发现一个新的可用服务，会向注册表注册此服务。服务管理器也负责注销终止的服务实例。
开源的服务管理器Register，负责自动注册和注销被部署的docker容器服务实例。Registrator支持多种服务管理器。包含etcd和Consul。

third-party Registration方式的优点是使服务和注册中心解耦，不用为每种语言实现服务注册的逻辑。这种方式的缺点就是必须得考虑该组件的高可用性。

服务发现的核心是服务注册中心。服务注册中心保存了各个服务可用的实例的相关信息。服务注册中心提供了管理API和查询API。使用管理API进行服务注册、注销。系统的其他组件可以通过查询API来获得当前可用的服务实例信息。

服务发现：服务端发现模式和客户端发现模式

客户端发现模式

客户端从服务注册中心查询所有可用服务实例的库，然后负责决定访问相应服务实例的网络位置，并且对请求实现负载均衡。
在服务启动的时候，向服务注册中心注册服务；在服务停止的时候，向服务注册中心注销服务。服务注册的一个典型的实现方式就是通过heartbeat机制定时刷新。

客户端发现方式的优缺点。由于客户端知道所有可用的服务的实际网络地址，所以可以非常方便的实现负载均衡功能（比如：一致性哈希）。但是这种方式有一个非常明显的缺点就是具有非常强的耦合性。针对不同的语言，每个服务的客户端都得实现一套服务发现的功能。

服务端发现模式

负载均衡器有服务端提供，客户端无需关注发现的细节。
客户端向load balancer 发送请求。load balancer 查询服务注册中心找到可用的服务，然后转发请求到该服务上。和客户端发现一样，服务都要到注册中心进行服务注册和注销。

服务器端发现方式的优点是，服务的发现逻辑对客户端是透明的。客户只需简单的向load balancer发送请求就可以了。这就避免了为每种不同语言的客户端实现一套发现的逻辑。此外，许多软件都内置实现了这种功能。这种方式的一个最大的缺点是，你必须得关心该组件的高可用性。
HTTP服务和类似Nginx的负载均衡器都可以作为服务端发现均衡器

服务发现和API网关

服务发现：为内部微服务提供服务注册和服务查询
API-Gateway：作为系统的唯一入口，对外部服务，提供反向路由，安全认证，限流，容错等能力
注：API-Gateway的路由信息，来源与服务发现模块

-----为了保证服务正常运行，服务注册中心应提供重试机制、限流、熔断机制、负载均衡、服务降级或者做本地缓存。

微服务整体构架