后台分布式架构形形色色，特别是微服务和云原生的兴起，诞生了一批批经典的分布式架构，然而在公司内部，或者其他大型互联网企业，都是抛出自己的架构，从接入层Controller，逻辑层Service，数据层Mapper都各有特点，但这些系统设计中到底是出于何种考量，有没有一些参考的脉络呢，本文将从云原生和微服务，有状态服务，无状态服务以及分布式系统等维度探讨这些脉络。
1.分布式系统概论
定义：《Designing Data-Intensive Application》指出分布式系统：通过网络进行通信的多台机器的系统
好处：
- 1.容错/高可用性：将应用程序部署在多台机器/网络/整个数据中心，保证任意宕机时仍可以继续工作。
- 2.可扩容性：负载均衡到多台机器。
- 3.低延迟：在全球各地设置服务器，保证每个用户都可以从最靠近他们地理位置的数据中心获取服务，避免用户等待网络包绕地球半圈响应请求。
- 4.资源弹性：可以设置云部署根据需求来扩展/收缩，保证每个用户只需要为实际使用的资源付费。
- 5.法律合规：有的数据符合的规则需要符合不同国家地区的政策，因此需要分布到多个位置的服务器上。
【DDIA这本书主要是基于有数据有状态来讨论分布式。】
但是，现实的实践中，分布式系统存在①有状态和②无状态：
- ①有状态：
- ②无状态：
2.实现分布式系统的模式
AO：【微服务的顶层】封装应用程序的业务逻辑和处理流程；负责处理用户请求，调用相关的原子服务来完成特定任务；与其他对象进行交互，协调不同的功能模块。
BO：【微服务中相关的原子服务】，负责业务原子化的服务[特定业务/数据打交道]；通常被各种AO服务调用
实现有状态的分布式系统，通常有以下三种：
2.1 单体应用
应用程序作为一个整体进行开发，测试和部署：
优点：
- 简单性：测试和部署更为简单。
- 性能较好：所有功能都在同一个进程中运行，有较好的性能和响应能力。
- 易于维护：所有代码和数据库都在同一个代码库和mysql库，很容易维护。
缺点：
- 系统复杂度高：随着功能的增加，代码库变得庞大和复杂，导致开发人员难以理解整个系统，进而影响代码的质量和维护性。
- 开发速度慢：由于需要编译、构建和测试整个项目，每次更改代码都会消耗大量时间，增加了开发成本。
- 难以扩展：单体应用难以根据不同模块的需求进行针对性的扩展，往往需要整体扩展，导致资源利用效率低下。
- 难以维护：模块之间的耦合度较高，修改一个模块的需求往往会带来连锁反应，影响其他模块的稳定性。
- 难以采用新技术：项目是一个庞大的整体，使得应用新技术的成本很高，因为必须对整个项目进行重构，这通常是不可能的。
- 开发速度慢：应用太大，每启动一次都需要很长时间，因此从编辑到构建、运行再到测试这个周期花费的时间越来越长。
- 部署困难：代码部署的周期很长，而且容易出问题。程序更改部署到生产环境的时间变得更长，代码库复杂，以至于一个更改可能引起的影响是未知的。
- 系统故障隔离差：应用程序缺乏故障隔离，因为所有模块都运行在同一个进程当中，任何部分的故障都可能影响整个系统的稳定性，导致宕机。
2.2 SOA架构–面向服务的架构
SOA架构关注于改变IT服务在企业范围内的工作方式，定义一种可通过服务接口复用软件组件并实现其互操作的方法。
优点：
- 可扩展性和灵活性：SOA 架构将系统拆分成独立的服务，可以按需组合和重组这些服务，从而实现系统的快速扩展和灵活部署。
- 提高系统的可重用性：每个服务都是独立的功能单元，可以在不同的系统中复用，提高了系统的开发效率和维护成本。
- 降低系统的耦合性：SOA 架构通过服务之间的松耦合关系，降低了服务之间的依赖性，有利于系统的模块化和维护。
- 提高系统的稳定性和可靠性：SOA 架构采用了服务注册与发现机制、负载均衡、故障恢复等机制，提高了系统的稳定性和可靠性。
缺点：
- 系统复杂度高：SOA 架构中涉及多个服务之间的协作和通信，系统的复杂度较高，开发、测试和维护成本相对较高。
- 性能问题：由于服务之间的通信需要通过网络进行，可能存在网络延迟和性能损失，对系统的性能造成影响。
- 安全性难以保障：SOA 架构中涉及多个服务之间的通信，需要对数据传输进行加密和安全控制，保障系统的安全性比较困难。
- 部署和运维难度大：SOA 架构中涉及多个服务的部署和管理，需要专门的运维团队进行管理，增加了系统的复杂性和运维成本。
2.3 微服务
【SOA架构的一种变体】微服务架构是一种云原生架构常用的实现方式—更强调基于云原生，独立部署，Devops，持续交付。
优点：
可扩展性和灵活性：SOA 架构将系统拆分成独立的服务，可以按需组合和重组这些服务，从而实现系统的快速扩展和灵活部署。
提高系统的可重用性：每个服务都是独立的功能单元，可以在不同的系统中复用，提高了系统的开发效率和维护成本。
降低系统的耦合性：SOA 架构通过服务之间的松耦合关系，降低了服务之间的依赖性，有利于系统的模块化和维护。
提高系统的稳定性和可靠性：SOA 架构采用了服务注册与发现机制、负载均衡、故障恢复等机制，提高了系统的稳定性和可靠性
【基于SOA架构新增的优点】
独立性：每个服务可以独立部署和更新，提高了系统的灵活性和可靠性。
可扩展性：根据需求，可以独立扩展单个服务，而不是整个应用程序。
容错性：单个服务的故障不会影响其他服务，提高了系统的稳定性。
缺点：
【基于SOA架构，主要在运维和部署上增加了难度！！！】
需要处理的问题：
- 必须有接入层：如上图，微服务化后，必然存在用户需要直接链接后端服务，那么这个时候就需要网关来解耦这块，也就是上面接入层讨论的好处。
- 服务容错：多个微服务部署在云上，不同母机，会带来通讯的复杂性，网络问题会成为常态，那么如何容灾，容错，降级，也是需要考虑的。
- 服务发现：当服务 A 发布或者扩缩容时，依赖服务 A 的服务 X 如何在保持运行的前提下自动感知到服务 A 的变化。这里需要引入第三方服务注册中心来实现服务的可发现性。比如北极星，stark，以及如何和容器，云原生结合。
- 服务部署：服务变成微服务之后，部署是分散，部署是独立的，就需要有一个可靠快速的部署，扩缩容方案，也包括 ci/cd，全链路、实时和多维度的可观测性等，如 tke，智妍等，k8s 就是解决这种问题的。
- 数据存储隔离：数据存储隔离(Data Storage Segregation, DSS) 原则，即数据是微服务的私有资产，必须通过当前微服务提供的 API 来访问数据，避免数据层产生耦合。对于有状态的微服务而言，通常使用计算与存储分类的方式，将数据下层到分布式存储方案中，从而一定程度上实现服务无状态化。
- 服务间调用：服务 A 采用什么方式才可以调用服务 X，由于服务自治的约束 ，服务之间的调用需要采用开发语言无关的远程调用协议。现在业界大部分的微服务架构通常采用基于 IDL （Interactive Data Language， 交互式数据语言）的二进制协议进行交互，如 pb。
而整体解决微服务问题的思路：
