微服务 - 简介
本节主要介绍微服务架构。
单体架构
简介
在软件设计中，经常提及和使用经典的 3 层模型，即表示层、业务逻辑层和数据访问层。
- 表示层：用于直接和用户交互，也称为交互层，通常是网页、UI 等。
- 业务逻辑层：即业务逻辑处理层，例如用户输入的信息要经过业务逻辑层的处理后，才能展现给用户。
- 数据访问层：用于操作数据库，用户在表示层会产生大量的数据，通过数据访问层对数据库进行读写操作。
单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。
单体架构的优缺点如下：
优点：
- 架构简单
- 部署成本低
缺点：
- 耦合度高（维护困难、升级困难）
单体架构存在的不足
随着应用业务的发展和业务复杂度的提高，这种架构明显存在很多的不足，主要体现在以下3个方面：
- 业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性下降，新人接手代码所需的时间成倍增加，业务扩展带来的代价越来越大。
- 随着用户量激增，程序承受的并发量激增，单体应用的并发能力成为瓶颈。
- 测试难度大，单体应用的业务都在同一个程序中，随着业务不断扩张、复杂度增加，导致单体应用修改业务必定或多或少地给其他业务带来影响，导致测试难度大。
单体集群架构的不足
针对上述的单体架构，进行改进，引入集群部署+负载均衡的技术，一定程度上提高系统的并发量和性能。但是仍然存在以下问题：
- 系统仍然是单体应用，没有改变代码的可读性、可维护性和可扩展性差的问题。
- 面对海量用户，数据库访问会成为瓶颈，需要采用分布式数据库，分库分表来解决。
- 持续交付能力差，业务代码复杂，新功能开发周期长，测试验证难度大。
微服务
概念
Microservices: a definition of this new architectural term
- The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
微服务架构的风格，就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来独立部署。这些服务可以使用不同的编程语言，以及不同数据存储技术，以保证低限度的集中式管理。
分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。
分布式架构的优缺点：
优点：
- 降低服务耦合
- 有利于服务升级和拓展
缺点：
- 服务调用关系错综复杂
分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：
- 服务拆分的粒度如何界定？ —— 以功能划分，减少耦合
- 服务之间如何调用？ —— 借助注册中心，查询所需调用的服务名，调用对应功能
- 进一步用MQ解耦，订单服务调用只需发送订单id=1的消息给borker，然后由borker调用后续商品，用户，支付等模块
- 服务的调用关系如何管理？ —— 基于HTTP的调用，服务只需对外暴露对应接口
人们需要制定一套行之有效的标准来约束分布式架构。
微服务的架构特征：
- 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
- 自治：团队独立、技术独立、数据独立，独立部署和交付
- 面向服务：服务提供统一标准的接口，与语言和技术无关
- 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
特点
- 按照业务来划分服务，单个服务代码量小，业务单一，易于维护。
- 每个微服务都有自己独立的基组件，例如数据库、缓存等，且运行在独立的进程中。
- 微服务之间的通信是通过HTTP协议或者消息组件，且具有容错能力。
- 微服务有一套服务治理的解决方案，服务之间不耦合，可以随时加入和剔除服务。
- 单个微服务能够集群化部署，并且有负载均衡的能力。
- 整个微服务系统应该有一个完整的安全机制，包括用户验证、权限验证、资源保护等。
- 整个微服务系统有链路追踪的能力。
- 有一套完整的实时日志系统。
常用组件
微服务组件：
服务注册与发现
- Eureka、Nacos、Consul 、Redis
- 所有微服务之间的调用，先通过注册中心，获取对应服务名的ip和端口信息，然后根据对应微服务暴露的接口，调用对应函数获取内容。
服务远程调用
OpenFegin、Dubbo、grpc、brpc
服务调用中，会有两个不同的角色：
服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）
服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）
关系：服务提供者与服务消费者的角色并不是绝对的，而是相对于业务而言。因此，一个服务既可以是服务提供者，也可以是服务消费者。
服务链路监控
- Zipkin、Sleuth
统一配置管理
- SpringCloudConfig、Nacos
统一网关路由
- SpringCloudGateway、Zuul
- 网关功能
- 身份认证和权限校验
- 服务路由、负载均衡
- 请求限流
流控、降级、保护
- Hystix、Sentinel
注意事项
- 事务：购买物品，需要账号扣款和商品数量-1，这两个操作存在不同的微服务中，整个过程发起一个事务流程，通过事务协调器TC来保证两者都是正确执行的情况下，才执行，否则需要回滚。
- 服务的部署：服务的启动顺序和启动时机
- 微服务架构的三大难题：服务故障的传播性(服务熔断、服务降级)、服务的划分和分布式事务(两阶段或三阶段提交)