微服务三个阶段
微服务三个阶段：
- 微服务1.0：仅使用注册发现，基于Spring Cloud 或 Dubbo开发。
- 微服务2.0：使用熔断、限流、降级等服务治理策略，并配备完整微服务工具和平台。
- 微服务3.0：Service Mesh将服务治理作为通用组件，下沉到平台层实现，使得应用层仅关注业务逻辑。
微服务1.0
微服务从2005年概念性的提出，到2014 Martin Flower详细阐述了微服务，定义微服务提到的小而专。
紧接着Spring Boot框架发布了1.0，本着约定大于配置的原则，来简化spring应用的初始化搭建及开发过程。
彼时笔者公司项目还是以SpringMvc搭建的单体应用为主，bean配置写在xml中。业务逻辑都在同一个jar包中，jar包体积非常大。开发简单，部署简单。但多人协作，代码冲突，应用频繁发版带来的问题不在少数。
Spring Boot版本时间线
到2017年笔者入职新公司，开始接触微服务框架Spring Cloud 和 Dubbo，来到了微服务1.0阶段。
在1.0阶段主要是通过框架整合注册中心组件来实现服务注册、查找。
常见注册中心有ZooKeeper、Eureka。
ZooKeeper
ZooKeeper提供高可用且具有严格顺序访问控制能力的分布式协调系统。本质上来说是一个强一致性的产品，在集群发生分区时会优先保证一致性而舍弃可用性，CP架构。
ZooKeeper的每个服务端存储的数据都是一致的，整个服务集群中存在唯一一个通过选举得到的主节点，客户端连接到任意一个ZooKeeper的服务端都能够得到一致的最新数据副本。
ZooKeeper通过消息传递保持分布式节点之间的数据一致性。ZooKeeper基于对Paxos进行裁剪的Zab协议，实现了一种主备模式的系统架构来保持服务端集群中各个副本之间的数据一致性。
在主节点崩溃的情况下，Zab协议通过主节点快速选举、初始化、同步从节点、广播这几个阶段来保证数据的一致性和主节点选举的高效性。
Eureka
Eureka优先保证了可用性，采用了去中心化的设计理念，整个服务集群由对等节点组成，不需要选举主节点。集群中失效的节点不会影响正常节点对外提供服务注册和服务查询能力。
如果向某个Eureka服务器注册服务时发现连接失败，会自动切换自其它节点。
- Register（服务注册）：IP、Port 注册到Eureka。
- Renew（服务续约）：发送心跳包，30秒发送一次，每一次收到心跳续约90秒。
- Cancel（服务下线）：服务下线 Eureka 会把此提供者从列表中移除。
- Get Registry：获取服务注册列表。
- Replicate：集群中数据同步和复制。
- Make Remote Call：完成服务的远程调用。
微服务2.0
在全面拥抱微服务后，我们按照Martin Flower定义的小而专来分解业务，拆分应用。
在微服务2.0阶段，我们的服务拆分的更细了。遇到的问题也更多了。
应用层问题:
- 服务雪崩：熔断机制处理，使用Fallback数据保证流程在下游服务不可用情况下，服务仍然可用。可用熔断限流框架 Sentinel实现。
- 大量请求堆积、故障恢复慢：通过线程池和消息队列机制实现异步化，允许服务快速失败，当某个服务过慢而阻塞，被影响服务在超时后快速失败，不影响整个链路。
基础设施层问题：
- 服务器资源分配困难，管理困难：统一基础设施，拥抱容器标准，解决服务之间隔离问题。
- 单台服务器上多个进程互相影响、QoS（服务质量）难以保障：统一编排和弹性伸缩平台，拥抱K8S标准，解决环境不一致问题。
- 环境多，环境管理、部署更新困难：打造CI/CD服务，实现从代码到测试到上线的自动部署。
服务细分带来的问题：
- 微服务框架不统一，业务定制化严重：统一用Spring Cloud，Dubbo等开源技术栈，将服务治理逻辑抽离，以无侵入方式实现。
- 传统监控无法满足：全链路跟踪服务与日志服务依据ID联系，以发现故障点上下文，比如链路监控Skywalking，指标监控Prometheus。
- API版本管理混乱，无统一监控、治理方式：服务通过API网关暴露，引入API管理，测试平台。
当然，服务治理不仅包含熔断、限流，还有负载均衡、超时、重试、服务追踪等。
微服务3.0
来到了微服务3.0时代，回头看看Spring Cloud和Dubbo架构存在的一些问题：
- 侵入性：服务治理实现方式和生命周期与业务逻辑是耦合在一起的，能力的增强需要微服务框架的升级，导致升级维护成本高；
- 实现绑定：微服务框架代码通常由特定语言实现，难以支持多语言实现，异构系统间的集成逐渐成为挑战。
于是社区提出了Service Mesh(服务网格)架构：业务逻辑与服务治理能力解耦，在服务消费者和提供者两侧以独立进程部署。达到去中心化的目的，保障系统的可伸缩性。
Service Mesh通过Sidecar的方式，将控制面和数据面隔离，通过非侵入模式进行流量拦截，实现真正的治理平台化。
网图
参考资料
- 《未来架构：从服务化到云原生》
- 《架构师（2019年第3期）》
