微服务介绍之系统架构的演变
随着互联网的发展，网站应用的规模也在不断扩大，进而导致系统架构也在不断的进行变化。
从互联网兴起到现在，系统架构大致经历了以下几个过程：
- 单体应用架构
- 垂直应用架构
- 分布式应用架构
- SOA架构
- 微服务架构
- Service Mesh(服务网格化)
- 无服务化
1.1 单体应用架构
互联网早期，一般的网站应用流量较小，只需要一个应用，将所有的功能代码都部署在一起就可以，这样可以减少开发，部署和维护的成本。
比如说一个电商系统，里面包含用户管理，商品管理，订单管理，物流管理等，我们把它做成一个web项目，并打包成war包，部署在一个tomcat上。
优点：
- 项目架构简单，适合小型项目，开发成本低
- 项目部署在一个节点上，维护方便
缺点：
- 全部功能集成在一个工程中，对大型项目来说，不易开发和维护
- 项目模块之间紧密耦合，单点容错率低
- 无法针对不同模块进行针对性优化和水平扩展
1.2 垂直应用架构
随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候你会发现，并不是所有的模块都会有比较大的访问量。
以电商系统为例子，用户访问量的增加会影响用户管理模块和订单模块等，对营销管理，运营管理系统等可能影响较小，这时候我们希望只增加用户管理和订单管理的节点，但是单体应用架构无法做到，这时候垂直应用架构诞生了。
所谓的垂直应用架构，就是将原来的一个应用拆分成互不相干的几个应用，以提升效率。
比如我们可以对电商系统进行拆分：
- 电商系统（用户管理，订单管理，商品管理等）
- 运营管理系统（商家管理，活动管理，客服系统，订单管理，用户管理，商品管理等）
- CMS系统（广告系统，营销管理等）
这样拆分完成之后，一旦用户的访问量变大，只需要增加电商系统的节点就可以了，而无需增加运营管理系统和CMS系统的节点。
1.3 分布式架构
当垂直应用越来越多，重复的业务代码就会越来越多。
比如运营管理系统也需要对订单，用户，商品等做管理。
营销管理中也需要对订单做相关的调用。
这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层做为独立的服务，然后由前端控制层调用不同的业务层服务呢？
这就产生了新的架构，分布式架构。
它将工程拆分为表现层和服务层两部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来进行实现。服务层可以部署多个节点来提升系统的性能。
优点：
- 抽取公共的功能为服务层，提高代码复用性
缺点：
- 系统间耦合度变高，调用关系错综复杂，难以维护
- 当服务节点过多后，表现层需要维护的信息也变的过多，更进一步增加了维护的难度。
1.4 SOA架构
在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行管理。
在SOA架构中，通常这个调度中心被称为注册中心。服务层将服务注册在注册中心，表现层只需要向注册中心索要服务地址即可，负载均衡，心跳检测等都由注册中心(SOA架构的核心)来实现。
优点：
- 使用注册中心，解决了服务间的调用关系
- 扩展也大大增强
缺点：
- 服务和服务之间有耦合，比如说多个服务使用同一个数据库服务
- 服务关系复杂，无法独立执行，部署，增加了运维和测试的难度
1.5 微服务架构
微服务架构从某种程度上来说，是对SOA架构的延伸，它强调服务的彻底拆分。
服务原子化。每一个服务都可以独立部署，独立运行，独立升级，独立扩展，有自己的数据库服务。
此时的服务称为“微服务”。
现代微服务的定义：微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维
优点：
- 服务原子化，每个服务任务清晰，易于扩展维护
缺点：
- 维护成本过高（容错，分布式事务等）
2. 微服务架构介绍
2.1 微服务架构的常见问题
一旦采用微服务架构，势必会遇到这样几个问题：
- 这么多小服务，如何管理它们？（服务治理，注册中心【服务注册，发现，剔除】）
- 这么多小服务，它们之间如何通讯？（restful RPC）
- 这么多小服务，客户端怎么访问他们？（网关）
- 这么多小服务，如果出现问题，如何自处理？（容错）
- 这么多小服务，一旦出现问题，应该如何排错？（链路追踪）
对于上面的问题，是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。
微服务完整的架构图：
2.2 微服务架构的常见概念
2.2.1 服务治理
服务治理就是进行服务的自动化管理，其核心是服务的自动注册与发现。
服务注册： 服务实例将自身服务信息注册到注册中心。
服务发现： 服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。
服务剔除： 服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。
2.2.2 服务调用
在微服务架构中，通常存在多个服务之间的远程调用需求。
目前主流的远程调用技术有基于HTTP的RESTFUL接口和基于TCP的RPC协议。
- REST： 这是一种HTTP的调用格式，更标准，更通用，无论哪种语言都支持http协议。
- RPC： 一种进程间的通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要作用就是让远程服务调用更简单，透明。RPC框架负责屏蔽底层的传输方式，序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。
区别与联系：
| 比较项 | Restful | RPC |
|---|---|---|
| 通讯协议 | HTTP | 一般使用TCP |
| 性能 | 略低 | 较高 |
| 灵活度 | 高 | 较高 |
2.2.3 服务网关
随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如何让客户端直接与各个微服务通信可能出现：
- 客户端需要调用不同的url地址，增加难度
- 在一定的场景下，存在跨域请求的问题
- 每个微服务都需要单独进行身份认证
- 微服务可能使用的协议不同，客户端需要进行适配
- 客户端需要自己实现负载均衡
- …
针对这些问题，API网关顺势而生。
API网关字面意思上理解，是将所有的API调用都接入到API网关，由网关层统一接入和输出。
一个网关的基本功能有：
- 统一接入
- 安全防护
- 协议适配
- 流量管控
- 长短链接支持
- 容错能力
- 负载均衡
有了网关之后，各个API服务提供团队可以专注于自己的业务逻辑处理，而API网关更专注于安全，流量，路由等问题。
2.2.4 服务容错
在微服务当中，一个请求经常会设计调用几个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。
我们没法预防雪崩效应的发生，只能尽可能去做好容错。
服务容错的三个核心思想：
- 不被外界环境影响
- 不被上游请求压垮
- 不被下游响应拖垮
2.2.5 链路追踪
随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发，可能使用不同的编程语言来实现，有可能部署在了几千台，上万台服务器上，横跨多个不同的数据中心。
因此需要对一次请求涉及的多个服务链路进行日志记录，性能监控。
这就是链路追踪。
2.3 微服务架构的常见解决方案
2.3.1 ServiceComb
https://servicecomb.apache.org/
Apache ServiceComb 是一个微服务的开源解决方案。其包含多个组件，通过组件之间的搭配，可以灵活的应对不同的场景。
Apache ServiceComb 提供了融合开源生态的一站式微服务开源解决方案，致力于帮助企业、用户和开发者将应用轻松微服务化上云，实现对微服务应用的高效运维管理。
华为开源的。
2.3.2 Spring Cloud
Spring Cloud是一系列框架的集合。它利用Spring Boot的开发便利性巧妙的简化了分布式系统基础设施的开发，如服务发现注册，配置中心，消息总线，负载均衡，断路器，数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复造轮子，它只是将目前各家公司开发比较成熟的，经得起实际考验的服务框架组合起来，通过Spring Boot风格进行在封装，屏蔽掉了服务的配置和实现原理，最终给开发者留出了一套简单易懂，易部署和易维护的分布式系统开发工具包。
2.3.3 Spring Cloud Alibaba
Spring Cloud Alibaba为分布式应用程序开发提供一站式解决方案。它包含开发分布式应用程序所需的所有组件，使您可以轻松使用Spring Cloud开发您的应用程序。
使用Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将Spring Cloud程序接入Alibaba的分布式解决方案，并使用阿里巴巴中间件构建分布式应用系统。
3. Spring Cloud Alibaba介绍
3.1 主要功能
- 服务限流降级：默认支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ 限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。
- 服务注册与发现：适配 Spring Cloud 服务注册与发现标准，默认集成了 Ribbon 的支持，使用Alibaba Nacos。
- 分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新，使用Alibaba Nacos。
- 消息驱动能力：基于 Spring Cloud Stream 为微服务应用构建消息驱动能力，配合RocketMQ使用。
- 分布式事务：使用 @GlobalTransactional 注解， 高效并且对业务零侵入地解决分布式事务问题，使用Seata。
- 阿里云对象存储：阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。
- 分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有 Worker（schedulerx-client）上执行。
- 阿里云短信服务：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。
官方介绍：https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md
3.2 组件
官方介绍：https://github.com/alibaba/spring-cloud-alibaba/blob/master/Roadmap-zh.md
Sentinel
阿里巴巴开源产品，把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Nacos
阿里巴巴开源产品，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
RocketMQ
Apache RocketMQ™ 基于 Java 的高性能、高吞吐量的分布式消息和流计算平台。
Dubbo
Apache Dubbo™ 是一款高性能 Java RPC 框架。
Seata
阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
Alibaba Cloud OSS
阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
Alibaba Cloud SchedulerX
阿里中间件团队开发的一款分布式任务调度产品，支持周期性的任务与固定时间点触发任务。
Alibaba Cloud SMS
覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。