服务演进概述

单体应用-> SOA ->微服务

持续集成，持续部署，持续交付。

集成:是指软件个人研发的部分向软件整体部分集成，以便尽早发现个人开发部分的问题；

部署: 是指代码尽可能快的向可运行的开发/测试节点交付，以便尽早测试；

交付: 是指研发尽可能快的向客户交付，以便尽早发现生产环境中存在的问题。

如果说等到所有东西都完成了才向下个环节交付，导致所有的问题只能在最后才爆发出来，解决成本巨大甚至无法解决。而所谓的持续，就是说每完成一个完整的部分，就向下个环节交付，发现问题可以马上调整。使问题不会放大到其他部分和后面的环节。

这种做法的核心思想在于：既然事实上难以做到事先完全了解完整的、正确的需求，那么就干脆一小块一小块的做，并且加快交付的速度和频率，使得交付物尽早在下个环节得到验证。早发现问题早返工。

持续集成工具：Jenkins（https://jenkins.io/doc/book/pipeline/）

单体应用

1. 概念：所有功能全部打包在一起。应用大部分是一个 war 包或 jar 包。随着业务发展，功能增多，项目会越来越臃肿。
   
2. 好处：容易开发、测试、部署，适合项目初期试错。
   
3. 坏处：
   随着项目越来越复杂，团队不断扩大。坏处就显现出来了。
   

• • 复杂性高：代码多，十万行，百万行级别。加一个小功能，会带来其他功能的隐患，因为它们聚合在一起。
    
  • 技术债务：人员流动，不坏不修，因为不敢修。
    
  • 持续部署困难：由于是全量应用，改一个小功能，全部部署，会导致无关的功能暂停使用。编译部署上线耗时长，不敢随便部署，导致部署频率低，进而又导致两次部署之间功能修改多，从而更不敢部署，恶性循环。
    
  • 可靠性差：某个小问题，比如小功能出现 OOM，会导致整个应用崩溃。
    
  • 扩展受限：只能整体扩展，无法按需扩展， 不能根据计算密集型（电商系统）和 IO 密集型（文件服务） 进行合适的区分。
    
  • 阻碍创新：单体应用是以一种技术解决所有问题，不容易引入新技术。但在高速的互联网发展过程中，适应的潮流是：用合适的语言做合适的事情。比如在单体应用中，一个项目用 Spring MVC，想换成 Spring Boot，切换成本很高，因为有可能10万，百万行代码都要改，而微服务可以轻松切换，因为每个服务，功能简单，代码少。
    

SOA

对单体应用的改进：引入 SOA（Service-Oriented Architecture）面向服务架构，拆分系统，用服务的流程化来实现业务的灵活性。服务间需要某些方法进行连接，面向接口等，它是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。但是还是需要用些方法来进行服务组合，有可能还是个单体应用。

所以引入微服务，是 SOA 思想的一种具体实践。

微服务架构 = 80%的 SOA 服务架构思想 + 100%的组件化架构思想。

微服务

微服务概况

• 无严格定义。
  
• 微服务是一种架构风格，将单体应用划分为小型的服务单元。
  
• 微服务架构是一种使用一系列粒度较小的服务来开发单个应用的方式；每个服务运行在自己的进程中；服务间采用轻量级的方式进行通信(通常是 HTTP API)；这些服务是基于业务逻辑和范围，通过自动化部署的机制来独立部署的，并且服务的集中管理应该是最低限度的，即每个服务可以采用不同的编程语言编写，使用不同的数据存储技术。
  
• 英文定义：http://www.martinfowler.com/articles/microservices.html
  
• 小类比
  合久必分。分开后通信，独立部署，独立存储。
  

• • 服从服务管理
    
  • 各自完成各自的一块业务
    
  • 服务间互相调用
    
  • 分担流量压力
    

微服务特性

• 独立运行在自己进程中
  
• 一系列独立服务共同构建起整个系统
  
• 一个服务只关注自己的独立业务
  
• 轻量的通信机制 RESTful API
  
• 使用不同语言开发
  
• 使用不同的数据存储技术
  
• 全自动部署机制
  

微服务组件介绍

不局限于具体的微服务实现技术。

• 服务注册与发现：服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址发起调用。
  
• 负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，服务节点选择的过程对服务调用方来说是透明的。
  
• 服务网关：服务网关是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。
  

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行 A/B 测试，即让一部分用户继续用产品特性 A，一部分用户开始用产品特性 B，如果用户对 B 没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到 B 上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

• 配置中心：将本地化的配置信息(Properties、XML、YAML 等形式)注册到配置中心，实现程序包在开发、测试、生产环境中的无差别性，方便程序包的迁移，也是无状态特性。
  
• 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件(特别是管理端组件)集成到统一的界面框架下，让用户能够在统一的界面中使用系统。Spring Cloud 就是一个集成框架。
  
• 调用链监控：记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
  
• 支撑平台：系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，这就需要将大部分的工作自动化。现在，Docker 等工具可以给微服务架构的部署带来较多的便利，例如持续集成、蓝绿发布、健康检查、性能监控等等。如果没有合适的支撑平台或工具，微服务架构就无法发挥它最大的功效。
  

1. 蓝绿部署是不停老版本，部署新版本然后进行测试，确认 OK，将流量切到新版本，然后老版本同时也升级到新版本。

2. 灰度是选择部分部署新版本，将部分流量引入到新版本，新老版本同时提供服务。等待灰度的版本 OK，可全量覆盖老版本。

灰度是不同版本共存，蓝绿是新旧版本切换，两种模式的出发点不一样。

微服务优点

1. 独立部署。不依赖其他服务，耦合性低，不用管其他服务的部署对自身的影响。
   
2. 服务聚焦，聚焦于业务。松耦合。
   
3. 易于开发和维护：关注特定业务，所以业务清晰，代码量少，模块变的易开发、易理解、易维护。
   
4. 启动快：功能少，代码少，所以启动快，有需要停机维护的服务，不会长时间暂停服务。
   
5. 局部修改容易：只需要部署相应的服务即可，适合敏捷开发。
   
6. 技术栈不受限：java，node.js 等。
   
7. 按需伸缩：某个服务受限，可以按需增加内存，cpu 等。
   
8. 职责专一。专门团队负责专门业务，有利于团队分工。
   
9. 代码复用。不需要重复写。底层实现通过接口方式提供。
   
10. 便于团队协作：每个团队只需要提供 API 就行，定义好 API 后，可以并行开发。
    

微服务缺点

1. 分布式固有的复杂性：容错（某个服务宕机），网络延时，调用关系、分布式事务等，都会带来复杂。
   
2. 分布式事务的挑战：每个服务有自己的数据库，优点在于不同服务可以选择适合自身业务的数据库。订单用 MySQL，评论用 MongoDB 等。目前最理想的解决方案是：柔性事务的最终一致性。
   

刚性事务：遵循 ACID 原则，强一致性。

柔性事务：遵循 BASE 理论，最终一致性；与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。

BASE 是 Basically Available(基本可用)、Soft State(软状态)和 Eventually Consistent (最终一致性)三个短语的缩写。BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障时允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足 BASE 理论的事务，我们称之为“柔性事务”。

1. 接口调整成本高：改一个接口，调用方都要改。
   
2. 增加了系统间通信成本。
   
3. 测试难度提升：一个接口改变，所有调用方都得测。自动化测试就变的重要了。API 文档的管理也尤为重要。推荐：yapi。
   
4. 运维要求高：需要维护几十上百个服务。监控变的复杂。并且还要关注多个集群，不像原来单体，一个应用正常运行即可。
   
5. 重复工作：比如 java 的工具类可以在共享 common.jar 中，但在多语言下行不通，C++ 无法直接用 java 的 jar 包。
   

设计原则

单一职责原则：关注整个系统功能中单独，有界限的一部分。

服务自治原则：可以独立开发，测试，构建，部署，运行，与其他服务解耦。

轻量级通信原则：轻，跨平台，跨语言。REST,AMQP 等。

粒度把控：与自己实际相结合。 不要追求完美，随业务进化而调整。（推荐书籍：《淘宝技术这10年》）

技术选型

1. Spring Cloud 和 Dubbo 组件比较
   

Dubbo：Zookeeper+Dubbo+SpringMVC/SpringBoot

通信方式：RPC

注册中心：Zookeeper，Nacos

配置中心：Diamond（淘宝开发）

Spring Cloud：Spring+Netflix

通信方式：Http RESTful

注册中心：Eureka，Consul，Nacos

配置中心：Config

断路器：Hystrix

网关：Zuul，Gateway

分布式追踪系统：Sleuth+Zipkin

1. 差别
   

Spring Cloud 简介

Spring Cloud 是实现微服务架构的一系列框架的有机集合。是在 Spring Boot 基础上构建的，用于简化分布式系统构建的工具集。是拥有众多子项目的项目集合。利用 Spring Boot 的开发便利性，巧妙地简化了分布式系统基础设施（服务注册与发现、熔断机制、网关路由、配置中心、消息总线、负载均衡、链路追踪等）的开发。

版本演进

1. 版本过程：版本名.版本号。
   
2. 版本名：伦敦地铁字母顺序。
   
3. 版本号
   

• • M（milestone）：里程碑
    
  • SR（Service Releases）：稳定版
    
  • RC（Release Candidate）：稳定版的候选版，也就是稳定版的最后一个版本
    

可以在 Spring Cloud 官网：https://spring.io/projects/spring-cloud 查看各个版本，目前的最新版本为 2021.0.0。

Spring Cloud 自 2016 年 1 月发布第一个 Angel.SR5 版本，到 2020 年 7 月发布 Hoxton.SR7 版本，已经历经了 4 年时间。这 4 年时间里，Spring Cloud 一共发布了 46 个版本，支持的组件数从 5 个增加到 21 个。Spring Cloud 在 2019 年 12 月对外宣布后续 RoadMap：

• 下一个版本 Ilford 版本是一个大版本。这个版本基于 Spring Framework 5.3 & Spring Boot 2.4，会在 2020 Q4 左右发布；
  
• Ilford 版本会删除处于维护模式的项目。目前处于维护模式的 Netflix 大部分项目都会被删除（spring-cloud-netflix Github 项目已经删除了这些维护模式的项目）；
  
• 简化 Spring Cloud 发布列车。后续 IaaS 厂商对应的 Spring Cloud 项目会移出 Spring Cloud 组织，各自单独维护（spring-cloud-azure 一直都是单独维护，spring-cloud-alibaba 孵化在 Spring Cloud 组织，毕业后单独维护）；
  
• API 重构，会带来重大的改变（Spring Cloud Hoxton 版本新增了 Spring Cloud Circuit Breaker 用于统一熔断操作的编程模型和 Spring Cloud LoadBalanacer 用于处理客户端负载均衡并代替 Netflix Ribbon）。
  

这个 RoadMap 可以说是对 Spring Cloud 有着非常大的变化。

组件

1. 服务注册与发现组件：Eureka，Zookeeper，Consul，Nacos 等。Eureka 基于 REST 风格的。
   
2. 服务调用组件：Hystrix (熔断降级，在出现依赖服务失效的情况下，通过隔离系统依赖服务的方式，防止服务级联失败，同时提供失败回滚机制，使系统能够更快地从异常中恢复)，Ribbon（客户端负载均衡，用于提供客户端的软件负载均衡算法，提供了一系列完善的配置项：连接超时、重试等），OpenFeign（优雅的封装 Ribbon，是一个声明式RESTful 网络请求客户端，它使编写 Web 服务客户端变得更加方便和快捷）。
   
3. 网关：路由和过滤。Zuul，Gateway。
   
4. 配置中心：Spring Cloud Config，提供了配置集中管理，动态刷新配置的功能；配置通过 Git 或者其他方式来存储。
   
5. 消息组件：Spring Cloud Stream（对分布式消息进行抽象，包括发布订阅、分组消费等功能，实现了微服务之间的异步通信）和 Spring Cloud Bus（主要提供服务间的事件通信，如刷新配置）。
   
6. 安全控制组件：Spring Cloud Security 基于 OAuth2.0 开放网络的安全标准，提供了单点登录、资源授权和令牌管理等功能。
   
7. 链路追踪组件：Spring Cloud Sleuth（收集调用链路上的数据），Zipkin（对 Sleuth 收集的信息，进行存储，统计，展示）。
   

SpringCloud替代实现

SpringCloud Alibaba

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。

Dubbo：Apache Dubbo 是一款高性能 Java RPC 框架。

Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。

Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。

Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。