总结

【2021-1-9】架构设计总结，阿里技术：架构整洁之道，书籍《架构整洁之道》
【2021-3-27】一个通过Web浏览器获取各种权限的页面，可用于前端测试

架构

迭代之路：

传统单体服务 -> 面向服务soa -> 微服务

如何画架构图

要让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体。那么，画架构图是为了：
- 解决沟通障碍
- 达成共识
- 减少歧义
比较流行的是4+1视图，分别为场景视图、逻辑视图、物理视图、处理流程视图和开发视图。
什么样的架构图是好架构图？
- 首先应该要明确其受众，再想清楚要给他们传递什么信息
- 所以，不要为了画一个物理视图去画物理视图，为了画一个逻辑视图去画逻辑视图，而应该根据受众的不同，传递的信息的不同，用图准确地表达出来，最后的图可能就是在这样一些分类里。
- 那么，画出的图好不好的一个直接标准就是：受众有没有准确接收到想传递的信息。
- 从受众角度来说，一个好的架构图是不需要解释的，应该是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。
- 问题：
  - 方框圆框、颜色、实线虚线什么意思？
C4 模型使用容器（应用程序、数据存储、微服务等）、组件和代码来描述一个软件系统的静态结构。
- 1、语境图(System Context Diagram)，有交互的周边系统
- 2、容器图(Container Diagram)，容器图是把语境图里待建设的系统做了一个展开。
- 3、组件图(Component Diagram)，把某个容器进行展开，描述其内部的模块。
- 4、类图(Code/Class Diagram)，给技术人员看的，比较常见
【2021-1-9】如何画出合格的技术架构图
可视化架构设计——C4介绍

UML图

【2021-2-19】UML中六种箭头含义：
- 总结：
  - 泛化、实现、依赖 → 关联 → 聚合 → 组合
- 泛化：一般与特殊、一般与具体之间的关系，表示继承关系
  - 实线空心三角箭头表示，子类 → 父类
- 实现：类与接口的关系,类是接口所有特征和行为的实现
  - 空心三角形箭头的虚线，实现类 → 接口类
- 依赖：一种使用的关系，即一个类的实现需要另一个类的协助
  - 虚线箭头，使用类A → 依赖类B
- 关联：类与类之间的联接,它使一个类知道另一个类的属性和方法，这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的。
  - 全局变量引用了另一个类，就表示关联了这个类
  - 实线箭头，类A → 类B
- 聚合：关联关系的一种特例，是强的关联关系。
  - 聚合是整体和个体之间的关系，即has-a的关系，整体与个体可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享。程序中聚合和关联关系是一致的，只能从语义级别来区分；
  - 尾部为空心菱形的实线箭头（也可以没箭头），student类 → teacher类（course+student）
- 组合：关联关系的一种特例。
  - 组合是一种整体与部分的关系，即contains-a的关系，比聚合更强。部分与整体的生命周期一致，整体的生命周期结束也就意味着部分的生命周期结束，组合关系不能共享。程序中组合和关联关系是一致的，只能从语义级别来区分。
  - 尾部为实心菱形的实现箭头（也可以没箭头），类A指向类B;
  - human类 → leg类+head类

客户端 vs 服务端

客户端 client，服务端 server

软件工程架构

C/S: 客户端、服务端
- 桌面级应用, 响应速度快，安全性强，个性化能力强，响应数据较快
B/S: 浏览器、服务器
- web应用可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢。

【2023-9-8】BS架构与CS架构的区别

C/S 客户端/服务端 – 两层架构

将任务合理分配到Client端和Server端，降低了系统的通讯开销，可以充分利用两端硬件环境的优势。早期的软件系统多以此作为首选设计标准。

C/S 架构是一种典型的两层架构，其全程是 Client/Server，即: 客户端/服务器端架构

客户端包含一个或多个在用户的电脑上运行的程序
服务器端有两种
- 一种是数据库服务器端，客户端通过数据库连接访问服务器端的数据；
- 另一种是Socket服务器端，服务器端的程序通过Socket与客户端的程序通信。
Client → Server
客户端程序 → 服务器（业务逻辑+数据库）

C/S 架构也可以看做是胖客户端架构。因为客户端需要实现绝大多数的业务逻辑和界面展示。这种架构中，作为客户端的部分需要承受很大的压力，因为显示逻辑和事务处理都包含在其中，通过与数据库的交互（通常是SQL或存储过程的实现）来达到持久化数据，以此满足实际项目的需要。

桌面级应用响应速度快，安全性强，个性化能力强，响应数据较快

B/S 浏览器/服务器 – 三层架构

随着Internet技术的兴起，对C/S结构的一种变化或者改进

用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现，形成所谓 3-tier结构。
借助不断成熟的WWW浏览器技术，结合浏览器的多种scrīpt语言(VBscrīpt、Javascrīpt…)和ActiveX技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。随着 98/Windows 2000将浏览器技术植入内部，这种结构更成为当今应用软件的首选体系结构。

B/S 架构全称为 Browser/Server，即浏览器/服务器结构。

Browser Web浏览器，极少数事务逻辑在前端实现，但主要事务逻辑在服务器端实现
Browser客户端，WebApp 服务器端 和 DB端 构成所谓的三层架构。
Browser → Web Server → Database Server
浏览器 → 服务器 → 数据库

B/S架构的系统无须特别安装，只有Web浏览器即可。

B/S架构中，显示逻辑交给了Web浏览器，事务处理逻辑在放在了WebApp上，避免了庞大的胖客户端，减少了客户端的压力。因为客户端包含的逻辑很少，因此也被成为瘦客户端。

web应用可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢。

B/S vs C/S

CS与BS的比较

C/S架构的两层、三层结构

对象	硬件环境	客户端要求	软件安装	升级和维护	安全性
`C/S`	用户固定，并且处于相同区域，要求拥有相同的操作系统。	客户端的计算机电脑配置要求较高。	每一个客户端都必须安装和配置软件.	C/S每一个客户端都要升级程序。可以采用自动升级。	一般面向相对固定的用户群，程序更加注重流程，它可以对权限进行多层次校验，提供了更安全的存取模式，对信息安全的控制能力很强。一般高度机密的信息	统采用C/S结构适宜。
`B/S`	要有操作系统和浏览器，与操作系统平台无关。	客户端的计算机电脑配置要求较低。	可以在任何地方进行操作而不用安装任何专门的软件。	不必安装及维护

客户端、服务端分工

客户端负责和用户交互，即屏幕显示(UI/UE)
服务端负责数据存储，也就是用户数据
而计算能力，客户端和服务端各负责一部分。

【2023-9-8】总结

架构整洁之道

架构设计的OKR

软件架构的目标（O）：最小化(需要构建和维护系统的)人力资源。
KR拆分：架构 → 模块 → 代码

编程范式

现有的编程范式有三种：
- 函数式编程（1936年）、面向对象编程（1966年）、结构化编程（1968年）
每种编程范式不是为程序员提供了更多的能力，而是限制能力。
- 结构化编程限制了控制权的直接转移；即限制了goto语句的使用
  - 结构化编程的本质：把大问题拆分成小问题，拆分成一块块可证伪的逻辑，这是对架构的最大启发，而goto语句会使得这种拆分变得困难。
  - 程序员可以用顺序结构、分支结构、循环结构这三种结构构造出任何程序。
- 面向对象编程限制了控制权的间接转移；即限制了函数指针的使用
  - 非面向对象的编程语言中，如何在互相解耦的组件间实现函数调用？答案是函数指针，void (open)(char name, int mode);
    - 这种方式非常脆弱，工程师必须严格按照约定初始化函数指针，并严格地按照约定来调用这些指针，只要一个人没有遵守约定，整个程序都会产生极其难以跟踪和消除的Bug。
  - 指针的使用，就是代码在原来的流程里不继续执行了，转而去执行别的代码，但具体执行了啥代码也不知道，只调了个函数指针或者接口。相对于goto的直接转移，这叫做控制权的间接转移。
  - 面向对象编程三大特性：封装、继承和多态
  - 面向对象编程限制了函数指针的使用，通过接口-实现、抽象类-继承等多态的方式来替代。
  - 多态更方便、安全地通过函数调用的方式进行组件间通信，是依赖反转（让依赖与控制流方向相反）的基础。
  - 面向对象编程对于架构的启发最大在于：多态。这使得跨越组件编程变得更安全，同时也是依赖倒置的基础。
- 函数式编程限制了赋值；
  - 函数式编程中，函数要保持独立，所有功能就是返回一个新的值，没有其他行为，尤其是不得修改外部变量的值。
  - 在架构领域所有的竞争问题、死锁问题、并发问题都是由可变变量导致的。如果有足够大的存储量和计算量，应用程序可以用事件溯源的方式，用完全不可变的函数式编程，只通过事务记录从头计算状态，就避免了前面提到的几个问题。目前要让一个软件系统完全没有可变变量是不现实的，但是我们可以通过将需要修改状态的部分和不需要修改的部分分隔成单独的组件，在不需要修改状态的组件中使用函数式编程，提高系统的稳定性和效率。
  - 所有并发程序（多核多线程）的问题，如果没有可变变量，就不再出现了。当然，这是不可能的，我们可以通过将需要修改状态的部分和不需要修改的部分分隔成单独的组件，在不需要修改状态的组件中使用函数式编程，提高系统的稳定性和效率。
总结
- 没有结构化编程，程序就无法从一块块可证伪的逻辑搭建
- 没有面向对象编程，跨越组件边界会是一个非常麻烦而危险的过程，而函数式编程，让组件更加高效而稳定。
- 没有编程范式，架构设计将无从谈起。

编程范式	限制能力	示例	架构启发
结构化	控制权直接转移	goto语句	大问题拆分成小问题
面向对象	控制权间接转移	函数指针	多态
函数式	赋值	可变变量

什么是好架构

网传的六边形架构、干净架构、洋葱架构、端口适配器架构都大同小异。
干净架构最核心的原则就是代码依赖关系只能从外向内。
干净架构的每一圈层代表软件系统的不同部分，越往里抽象程度越高。外层为机制，内层为策略。
具体组成
- (1) 实体（Entities）
  - 实体用于封装企业范围的业务规则。实体可以是拥有方法的对象，也可以是数据结构和函数的集合。如果没有企业，只是单个应用，那么实体就是应用里的业务对象。这些对象封装了最通用和高层的业务规则，极少会受到外部变化的影响。任何操作层面的改动都不会影响到这一层。
- (2) 用例（Use Cases）
  - 用例是特定于应用的业务逻辑，一般用来完成用户的某个操作。用例协调数据流向或者流出实体层，并且在此过程中通过执行实体的业务规则来达成用例的目标。用例层的改动不会影响到内部的实体层，同时也不会受外层的改动影响，比如数据库、UI 和框架的变动。只有而且应当应用的操作发生变化的时候，用例层的代码才随之修改。
- (3) 接口适配器（Interface Adapters）
  - 接口适配器层的主要作用是转换数据，数据从最适合内部用例层和实体层的结构转换成适合外层（比如数据持久化框架）的结构。反之，来自于外部服务的数据也会在这层转换为内层需要的结构。
- (4) 框架和驱动（Frameworks and Drivers）
  - 最外层由各种框架和工具组成，比如 Web 框架、数据库访问工具等。通常在这层不需要写太多代码，大多是一些用来跟内层通信的胶水代码。这一层包含了所有实现细节，把实现细节锁定在这一层能够减少它们的改动对整个系统造成的伤害。

如何设计架构

不妨反过来看，代码→ 模块→ 架构，先看什么是好的代码，如何更好的划分模块，再看什么是好的架构。
如何建一座房子？构造一个房子，会从砖块、房间、建筑三个维度来考虑
编程范式：如何更好构建好的砖块；
设计原则：如何更好将砖块构建成房间；
组件原则：如何更好将房间构建成建筑；
（1）架构设计原则：SOLID原则
- SRP（单一职责原则）；
  - 一个模块有且只能对一个角色负责，不是每个模块都只做一件事。单一职责原则要求我们分割不同角色依赖的代码。
  - 角色不只是人、或者是一群人，很可能是一个业务方
- OCP（开闭原则）；
  - 设计良好的软件应该对扩展开放，对修改关闭。这是架构设计的主导原则，其他原则都为这条原则服务。
  - 父类出现的地方可以用子类进行替换。具体到架构层面：该原则指导的是接口与其实现方式。
- LSP（里氏替换原则）；
  - 当用同一接口的不同实现互相替换时，系统的行为应该保持不变。程序中的对象应该可以被其子类实例替换掉，而不会影响程序的正确性
  - 不依赖任何不需要的方法、类或组件。该原则指导我们的接口设计，不要引入过多依赖。
- ISP（接口隔离原则）；
  - 不依赖任何不需要的方法、类或组件。该原则指导我们的接口设计，不要引入过多依赖。
  - 多个特定细分的接口比单一的总接口要好，不能强迫用户去依赖他们用不到的接口
- DIP（依赖反转原则）；
  - 程序要依赖于抽象接口，而不是具体实现。
    - 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
    - 抽象不应该依赖具体实现，具体实现应该依赖抽象
  - 依赖接口，而不是依赖实现。跨越组建边界的依赖方向永远与控制流的方向相反。该原则指导我们设计组件间依赖的方向。
  - 依赖反转原则是个可操作性非常强的原则，当你要修改组件间的依赖方向时，将需要进行组件间通信的类抽象为接口，接口放在边界的哪边，依赖就指向哪边。
开闭原则最重要，其他原则都为开闭原则服务
良好的软件应该易于扩展，同时抗拒修改
【2021-1-29】图解身边的SOLID原则
（2）组件拆分原则
- 哪些类应该归属到哪些模块？在组件的层级层面，不应该只是依赖经验，而应该有一些原则来指导。
- 4.1 复用、发布等同原则（REP）
  - 软件复用的最小粒度应等同于其发布最小粒度。
  - 直白地说，就是要复用一段代码就把它抽成组件。
  - 如何抽组件，需要共同闭包原则、共同复用原则来协同支撑。
- 4.2 共同封闭原则(CCP)
  - 为了相同目的而同时修改的类，应该放在同一个组件中。共同封闭原则是组件视角下的单一职责原则。
- 4.3 共同复用原则(CRP)
  - 不要强迫一个组件依赖它不需要的东西。共同复用原则是组件视觉下的接口隔离原则。
总结：
- REP 和 CCP 会让组件变得越来越大，CRP会让组件变得越来越小。
  - 如图，逆时针方向，边代表放弃该原则的代价。
    - 遵守REP、CCP 而忽略 CRP ，就会依赖了太多没有用到的组件和类，而这些组件或类的变动会导致你自己的组件进行太多不必要的发布；
    - 遵守 REP 、CRP 而忽略 CCP，因为组件拆分的太细了，一个需求变更可能要改n个组件，带来的成本也是巨大的。
- 架构师需要平衡上面三个原则的关系。
  - 1、项目开始倾向于张力图右侧，不考虑重用；
  - 2、随着项目进行，和其他项目脱胎出来，项目将滑向张力图的左侧；
（3）组件依赖原则 vs 架构
- 无循环依赖原则（ADP）
  - 这个很好理解，如果有循环依赖，那么会导致无关组件一起发布，一起部署。避免“早晨综合症”。
  - 如何处理循环依赖，可以使用依赖倒置原则，解除循环依赖。
- 稳定依赖原则 (SDP)
  - 依赖必须要指向更稳定（变更成本小）的方向。
    - 不稳定度 = F(代码量大小，复杂度，清晰度，依赖该模块的数目)
      ，和变化频繁不频繁没关系。
    - 不稳定性（I） = 出向依赖数量 / (入向依赖数量 + 出向依赖数量)。
- 稳定抽象原则（SAP）
  - 越稳定，越抽象。抽象程度（A）= 组件中抽象类和接口的数量 / 组件中类的数量。SDP描述依赖应该顺着稳定性的指向，SAP描述稳定性意味着要抽象，综合起来，依赖应该顺着要抽象的方向。
（4）总结
（5）如何设计好的架构
- 两个方针
  - 1、尽可能长时间地保留尽可能多的可选项。
    - 例如决定使用什么框架、使用什么数据库，业务代码要和这些可选项解耦，越晚你的信息越全，选型就越合适；
  - 2、低层次解耦方式能解决的，不要用高层次解耦方式。代码解耦 → 组件解耦 → 服务解耦，成本越来越高；
- 组件拆分原则
  - 组件拆分粒度关于要不要拆、拆到什么维度，要不要分层、分几层，没有银弹，这里也只能提供一些原则，这些原则是上面的抽象原则的具体化。从一个视角(例如：读写分离、服务隔离等) + 上面的各种原则，可能会对自己的服务的不合理之处有新的认知。
    - (1) 衡量成本。凡是拆分，必有成本（修改成本、部署发布成本），能用低层次拆分的不用高层次拆分组件（代码层面→线程层面→ 进程层面），该指标由：组件聚合原则之间的矛盾得出；
    - (2) 迭代快慢。受到函数式编程的启发，拆分不变与可变，架构层面我们可以根据变化快慢来拆分组件；
    - (3) 组织架构。复用、发布等效原则+单一职责原则；
    - (4) 稳定性需求。根据接口隔离原则，架构层面不应该让不稳定的组件影响稳定的组件；
摘自：知乎：如何评价 Bob 大叔的新书《架构整洁之道》？

数据架构

DAO

Spring Boot框架model层、dao层、service层、controller层分析设计

model层
- model层即数据库实体层，也被称为entity层，pojo层。
- 一般数据库一张表对应一个实体类，类属性同表字段一一对应。
dao层
- dao层即数据持久层，也被称为mapper层。
- dao层的作用为访问数据库，向数据库发送sql语句，完成数据的增删改查任务。
service层
- service层即业务逻辑层。
- service层的作用为完成功能设计。
- service层调用dao层接口，接收dao层返回的数据，完成项目的基本功能设计。
controller层
- controller层即控制层。
- controller层的功能为请求和响应控制。
- controller层负责前后端交互，接受前端请求，调用service层，接收service层返回的数据，最后返回具体的页面和数据到客户端。

DAO

MVC——Flask

MTV——Django

架构演进

【2021-5-11】图解：从单个服务器扩展到百万用户的系统

垂直扩展意味着在性能更强的计算机上运行同样的服务，而水平扩展是并行地运行多个服务。

如今，几乎没有人说垂直扩展了。原因很简单：

随着计算机性能的增长，其价格会成倍增长
单台计算机的性能是有上限的，不可能无限制地垂直扩展
多核CPU意味着即使是单台计算机也可以并行的。那么，为什么不一开始就并行化呢？

现在我们水平扩展服务。需要哪些步骤呢？

1.单台服务器 + 数据库

图

后端服务最初的样子。有一个执行业务逻辑的应用服务器（Application Server）和保存数据的数据库。看上去很不错。但是这样的配置，满足更高要求的唯一方法是在性能更强的计算机上运行，这点不是很好。

2. 增加一个反向代理

图

成为大规模服务架构的第一步是添加反向代理。代理是一个接收和转发请求的过程。正常情况下，「正向代理」代理的对象是客户端，「反向代理」代理的对象是服务端，它完成这些功能：

健康检查功能，确保我们的服务器是一直处于运行状态的
路由转发功能，把请求转发到正确的服务路径上
认证功能,确保用户有权限访问后端服务器
防火墙功能，确保用户只能访问允许使用的网络部分等等

3.引入负载均衡器

图

大多数反向代理还有另外一个功能：他们也可以充当负载均衡器。

负载均衡器是个简单概念，想象下有一百个用户在一分钟之内在你的网店里付款。遗憾的是，你的付款服务器在一分钟内只能处理50笔付款。这怎么办呢？同时运行两个付款服务器就行了。

负载均衡器的功能就是把付款请求分发到两台付款服务器上。用户1往左，用户2往右，用户3再往左。。。以此类推。

如果一次有500个用户需要立刻付款，这该怎么解决呢？确切地说，你可以扩展到十台付款服务器，之后让负载均衡器分发请求到这十台服务器上。

4. 扩展数据库

图

负载均衡器的使用使得我们可以在多个服务器之间分配负载。但是你发现问题了吗？尽管我们可以用成百上千台服务器处理请求，但是他们都是用同一个数据库存储和检索数据。

那么，我们不能以同样的方式来扩展数据库吗？很遗憾，这里有个一致性的问题。

系统使用的所有服务需要就他们使用的数据达成一致。数据不一致会导致各种问题，如订单被多次处理，从一个余额只有100元的账户中扣除两笔90元的付款等等……那么我们在扩展数据库的时候如何确保一致性呢？

我们需要做的第一件事是把数据库分成多个部分。一部分专门负责接收并存储数据，其他部分负责检索数据。这个方案有时称为主从模式或者单实例写多副本读。这里假设是从数据库读的频率高于写的频率。这个方案的好处是保证了一致性，因为数据只能被单实例写入，之后把写入数据同步到其他部分即可。缺点是我们仍然只有一个写数据库实例。

这对于中小型的Web应用来说没问题，但是像Facebook这样的则不会这样做了。我们会在第九节中研究扩展数据库的步骤。

5. 微服务

图

到目前为止，我们的付款、订单、库存、用户管理等等这些功能都在一台服务器上。

这也不是坏事，单个服务器同时意味着更低的复杂性。随着规模的增加，事情会变得复杂和低效：

开发团队随着应用的发展而增长。但是随着越来越多的开发人员工作在同一台服务器上，发生冲突的可能性很大。
仅有一台服务器，意味着每当我们发布新版本时，必须要等所有工作完成后才能发布。当一个团队想快速地发布而另外一个团队只完成了一半工作的时候，这种互相依赖性很危险。

对于这些问题的解决方案是一个新的架构范式：微服务，它已经在开发人员中掀起了风暴。

每个服务都可以单独扩展，更好地适应需求
开发团队之间相互独立，每个团队都负责自己的微服务生命周期(创建，部署，更新等)
每个微服务都有自己的资源，比如数据库，进一步缓解了第4节中的问题。

6. 缓存和内容分发网络(CDN)

图

有什么方式能使服务更高效? 网络应用的很大一部由静态资源构成,如图片、CSS样式文件、JavaScript脚本以及一些针对特定产品提前渲染好的页面等等。

我们使用缓存而不是对每个请求都重新处理，缓存用于记住最后一次的结果并交由其他服务或者客户端，这样就不用每次都请求后端服务了。

缓存的加强版叫内容分发网络（Content Delivery Network），遍布全球的大量缓存。这使得用户可以从物理上靠近他们的地方来获取网页内容，而不是每次都把数据从源头搬到用户那里。

7. 消息队列

图

政府机构、邮局、游乐园入口都属于并行概念的例子，多个售票亭同时售票，但似乎也永远不足以为每个人立即服务，于是队列形成了。

队列同样也是用于大型Web应用。每分钟都有成千上万的图片上传到Instagram、Facebook每个图片都需要处理，调整大小，分析与打标签，这些都是耗时的处理过程。

因此，不要让用户等到完成所有步骤，图片接收服务只需要做以下三件事：

存储原始的、未处理的图片
向用户确认图片已经上传
创建一个待办的任务

这个待办事项列表中的任务可以被其他任意数量服务接收，每个服务完成其中一个任务，直到所有的待办事项完成。管理这些“待办事项列表”的称为消息队列。使用这样的队列有许多优点：

解耦了任务和处理过程。有时需要处理大量的图片，有时很少。有时有大量服务可用，有时很少可用。简单地把任务添加到待办事项而不是直接处理它们，这确保了系统保持响应并且任务也不会丢失。可以按需扩展。启动大量的服务比较耗时，所以当有大量用户上传图片时再去启动服务，这已经太晚了。我们把任务添加到队列中，我们可以推迟提供额外的处理能力。好了，如果按照我们上面的所有步骤操作下来，我们的系统已经做好提供大流量服务的准备了。但是如果还想提供更大量的，该怎么做呢？还有一些可以做: 分片

8.分片，分片，还是分片

图

什么是分片？好吧，深呼吸一下，准备好了吗？我们看下定义：

“Sharding is a technique of parallelizing an application’s stacks by separating them into multiple units, each responsible for a certain key or namespace”

哎呦…… 分片究竟是是什么意思呢？

其实也很简单：Facebook上需要为20亿用户提供个人资料, 可以把你的应用架构分解为 26个mini-Facebook, 用户名如果以A开头，会被mini-facebook A处理，用户名如果以B开头，会被mini-facebook B来处理……

分片不一定按字母顺序，根据业务需要，你可以基于任何数量的因素，比如位置、使用频率(特权用户被路由到好的硬件)等等。你可以根据需要以这种方式切分服务器、数据库或其他方面。

9. 对负载均衡器进行负载均衡

图

到目前为止，我们一直使用一个负载均衡器，即使你购买的一些功能强悍(且其价格极其昂贵)的硬件负载均衡器，但是他们可以处理的请求量也存在硬件限制。

幸运地是，我们可以有一个全球性、分散且稳定的层，用于在请求达到负载均衡器之前对请求负载均衡。最棒的地方是免费，这是域名系统或简称DNS。DNS将域名(如arcentry.com)映射到IP，143.204.47.77。DNS允许我们为域名指定多个IP，每个IP都会解析到不同的负载均衡器。

你看，扩展Web应用确实需要考虑很多东西，感谢你和我们一起待了这么久。我希望这篇文章能给你一些有用的东西。但是如果你做任何IT领域相关的工作，你在阅读本文的时候，可能有个问题一直萦绕在你的脑海：”云服务是怎样的呢？”

Cloud Computing / Serverless

但是云服务如何呢？确实，它是上面许多问题最有效的解决方案。

你无需解决这些难题。相反，这些难题留给了云厂商，他们为我们提供一个系统，可以根据需求进行扩展，而不用担心错综复杂的问题。

例如。Arcentry网站不会执行上述讨论的任何操作(除了数据库的读写分离)，而只是把这些难题留给Amazon Web Service Lambda函数处理了，用户省去了烦恼。

淘宝架构演进

【2019-3-23】服务端高并发分布式架构演进之路

1. 概述

以淘宝为例，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。

特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非淘宝真正的技术演进路径

2. 基本概念

在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍：

分布式 ：系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上
高可用 ：系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性
集群：一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性
负载均衡 ：请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的
正向代理和反向代理 ：系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。

3. 架构演进

3.1 单机架构

以淘宝为例，在网站最初时，应用数量与用户数都较少，可以把Tomcat和数据库部署在同一台服务器上。浏览器往www.taobao.com发起请求时，首先经过DNS服务器（域名系统）把域名转换为实际IP地址10.102.4.1，浏览器转而访问该IP对应的Tomcat。

随着用户数的增长，Tomcat和数据库之间竞争资源，单机性能不足以支撑业务

3.2 第一次演进：Tomcat与数据库分开部署

Tomcat和数据库分别独占服务器资源，显著提高两者各自性能。

随着用户数的增长，并发读写数据库成为瓶颈

3.3 第二次演进：引入本地缓存和分布式缓存

在Tomcat同服务器上或同JVM中增加本地缓存，并在外部增加分布式缓存，缓存热门商品信息或热门商品的html页面等。通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。其中涉及的技术包括：使用memcached作为本地缓存，使用Redis作为分布式缓存，还会涉及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等问题。

缓存抗住了大部分的访问请求，随着用户数的增长，并发压力主要落在单机的Tomcat上，响应逐渐变慢

3.4 第三次演进：引入反向代理实现负载均衡

在多台服务器上分别部署Tomcat，使用反向代理软件（Nginx）把请求均匀分发到每个Tomcat中。此处假设Tomcat最多支持100个并发，Nginx最多支持50000个并发，那么理论上Nginx把请求分发到500个Tomcat上，就能抗住50000个并发。其中涉及的技术包括：Nginx、HAProxy，两者都是工作在网络第七层的反向代理软件，主要支持http协议，还会涉及session共享、文件上传下载的问题。

反向代理使应用服务器可支持的并发量大大增加，但并发量的增长也意味着更多请求穿透到数据库，单机的数据库最终成为瓶颈

3.5 第四次演进：数据库读写分离

把数据库划分为读库和写库，读库可以有多个，通过同步机制把写库的数据同步到读库，对于需要查询最新写入数据场景，可通过在缓存中多写一份，通过缓存获得最新数据。其中涉及的技术包括：Mycat，它是数据库中间件，可通过它来组织数据库的分离读写和分库分表，客户端通过它来访问下层数据库，还会涉及数据同步，数据一致性的问题。

业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能

3.6 第五次演进：数据库按业务分库

把不同业务的数据保存到不同的数据库中，使业务之间的资源竞争降低，对于访问量大的业务，可以部署更多的服务器来支撑。这样同时导致跨业务的表无法直接做关联分析，需要通过其他途径来解决，但这不是本文讨论的重点，有兴趣的可以自行搜索解决方案。

随着用户数的增长，单机的写库会逐渐会达到性能瓶颈

3.7 第六次演进：把大表拆分为小表

比如针对评论数据，可按照商品ID进行hash，路由到对应的表中存储；针对支付记录，可按照小时创建表，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据。只要实时操作的表数据量足够小，请求能够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能。其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制。

这种做法显著的增加了数据库运维的难度，对DBA的要求较高。数据库设计到这种结构时，已经可以称为分布式数据库，但是这只是一个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由Mycat实现，SQL的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果的汇总可能由数据库接口层来实现等等，这种架构其实是MPP（大规模并行处理）架构的一类实现。

目前开源和商用都已经有不少MPP数据库，开源中比较流行的有Greenplum、TiDB、Postgresql XC、HAWQ等，商用的如南大通用的GBase、睿帆科技的雪球DB、华为的LibrA等等，不同的MPP数据库的侧重点也不一样，如TiDB更侧重于分布式OLTP场景，Greenplum更侧重于分布式OLAP场景，这些MPP数据库基本都提供了类似Postgresql、Oracle、MySQL那样的SQL标准支持能力，能把一个查询解析为分布式的执行计划分发到每台机器上并行执行，最终由数据库本身汇总数据进行返回，也提供了诸如权限管理、分库分表、事务、数据副本等能力，并且大多能够支持100个节点以上的集群，大大降低了数据库运维的成本，并且使数据库也能够实现水平扩展。

数据库和Tomcat都能够水平扩展，可支撑的并发大幅提高，随着用户数的增长，最终单机的Nginx会成为瓶颈

3.8 第七次演进：使用LVS或F5来使多个Nginx负载均衡

由于瓶颈在Nginx，因此无法通过两层的Nginx来实现多个Nginx的负载均衡。图中的LVS和F5是工作在网络第四层的负载均衡解决方案，其中LVS是软件，运行在操作系统内核态，可对TCP请求或更高层级的网络协议进行转发，因此支持的协议更丰富，并且性能也远高于Nginx，可假设单机的LVS可支持几十万个并发的请求转发；F5是一种负载均衡硬件，与LVS提供的能力类似，性能比LVS更高，但价格昂贵。由于LVS是单机版的软件，若LVS所在服务器宕机则会导致整个后端系统都无法访问，因此需要有备用节点。可使用keepalived软件模拟出虚拟IP，然后把虚拟IP绑定到多台LVS服务器上，浏览器访问虚拟IP时，会被路由器重定向到真实的LVS服务器，当主LVS服务器宕机时，keepalived软件会自动更新路由器中的路由表，把虚拟IP重定向到另外一台正常的LVS服务器，从而达到LVS服务器高可用的效果。

此处需要注意的是，上图中从Nginx层到Tomcat层这样画并不代表全部Nginx都转发请求到全部的Tomcat，在实际使用时，可能会是几个Nginx下面接一部分的Tomcat，这些Nginx之间通过keepalived实现高可用，其他的Nginx接另外的Tomcat，这样可接入的Tomcat数量就能成倍的增加。

由于LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同

3.9 第八次演进：通过DNS轮询实现机房间的负载均衡

在DNS服务器中可配置一个域名对应多个IP地址，每个IP地址对应到不同的机房里的虚拟IP。当用户访问www.taobao.com时，DNS服务器会使用轮询策略或其他策略，来选择某个IP供用户访问。此方式能实现机房间的负载均衡，至此，系统可做到机房级别的水平扩展，千万级到亿级的并发量都可通过增加机房来解决，系统入口处的请求并发量不再是问题。

随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无法解决如此丰富的需求

3.10 第九次演进：引入NoSQL数据库和搜索引擎等技术

当数据库中的数据多到一定规模时，数据库就不适用于复杂的查询了，往往只能满足普通查询的场景。对于统计报表场景，在数据量大时不一定能跑出结果，而且在跑复杂查询时会导致其他查询变慢，对于全文检索、可变数据结构等场景，数据库天生不适用。因此需要针对特定的场景，引入合适的解决方案。如对于海量文件存储，可通过分布式文件系统HDFS解决，对于key value类型的数据，可通过HBase和Redis等方案解决，对于全文检索场景，可通过搜索引擎如ElasticSearch解决，对于多维分析场景，可通过Kylin或Druid等方案解决。

当然，引入更多组件同时会提高系统的复杂度，不同的组件保存的数据需要同步，需要考虑一致性的问题，需要有更多的运维手段来管理这些组件等。

引入更多组件解决了丰富的需求，业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务的升级迭代变得困难

3.11 第十次演进：大应用拆分为小应用

按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级迭代。这时候应用之间可能会涉及到一些公共配置，可以通过分布式配置中心Zookeeper来解决。

不同应用之间存在共用的模块，由应用单独管理会导致相同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级

3.12 第十一次演进：复用的功能抽离成微服务

如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。此外，可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。

不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱

3.13 第十二次演进：引入企业服务总线ESB屏蔽服务接口的访问差异

通过ESB统一进行访问协议转换，应用统一通过ESB来访问后端服务，服务与服务之间也通过ESB来相互调用，以此降低系统的耦合程度。这种单个应用拆分为多个应用，公共服务单独抽取出来来管理，并使用企业消息总线来解除服务之间耦合问题的架构，就是所谓的SOA（面向服务）架构，这种架构与微服务架构容易混淆，因为表现形式十分相似。个人理解，微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想，而SOA架构则是指一种拆分服务并使服务接口访问变得统一的架构思想，SOA架构中包含了微服务的思想。

业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难

3.14 第十三次演进：引入容器化技术实现运行环境隔离与动态服务管理

目前最流行的容器化技术是Docker，最流行的容器管理服务是Kubernetes(K8S)，应用/服务可以打包为Docker镜像，通过K8S来动态分发和部署镜像。Docker镜像可理解为一个能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运行环境根据实际的需要设置好。把整个“操作系统”打包为一个镜像后，就可以分发到需要部署相关服务的机器上，直接启动Docker镜像就可以把服务起起来，使服务的部署和运维变得简单。

在大促的之前，可以在现有的机器集群上划分出服务器来启动Docker镜像，增强服务的性能，大促过后就可以关闭镜像，对机器上的其他服务不造成影响（在3.14节之前，服务运行在新增机器上需要修改系统配置来适配服务，这会导致机器上其他服务需要的运行环境被破坏）。

使用容器化技术后服务动态扩缩容问题得以解决，但是机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低

3.15 第十四次演进：以云平台承载系统

系统可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题，在大促的时间段里，在云平台中临时申请更多的资源，结合Docker和K8S来快速部署服务，在大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维成本。

所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在之上可按需动态申请硬件资源（如CPU、内存、网络等），并且之上提供通用的操作系统，提供常用的技术组件（如Hadoop技术栈，MPP数据库等）供用户使用，甚至提供开发好的应用，用户不需要关系应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮件服务、个人博客等）。在云平台中会涉及如下几个概念：

IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；
PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；
SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。

至此，以上所提到的从高并发访问问题，到服务的架构和系统实施的层面都有了各自的解决方案，但同时也应该意识到，在上面的介绍中，其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题，这些问题以后有机会再拿出来单独讨论

4. 架构设计总结

架构的调整是否必须按照上述演变路径进行？
- 不是的，以上所说的架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。
对于将要实施的系统，架构应该设计到什么程度？
- 对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。
服务端架构和大数据架构有什么区别？
- 所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术，如数据采集有Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS，NoSQL数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。总的来说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。

有没有一些架构设计的原则？

N+1设计。系统中的每个组件都应做到没有单点故障；
回滚设计。确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
禁用设计。应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
监控设计。在设计阶段就要考虑监控的手段；
多活数据中心设计。若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
采用成熟的技术。刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
资源隔离设计。应避免单一业务占用全部资源；
架构应能水平扩展。系统只有做到能水平扩展，才能有效避免瓶颈问题；
非核心则购买。非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
使用商用硬件。商用硬件能有效降低硬件故障的机率；
快速迭代。系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
无状态设计。服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。

58架构

架构演进

【2021-5-12】好架构是进化来的，不是设计来的

第一章：建站之初

建站之初，站点流量非常小，可能低于十万级别。这意味着，平均每秒钟也就几次访问。请求量比较低，数据量比较小，代码量也比较小，几个工程师，很短的时间搭起这样的系统，甚至没有考虑“架构”的问题。

和许多创业公司初期一样，最初58同城的站点架构特点是“ALL-IN-ONE”：

好架构是进化来的，不是设计来的（58架构演进）

这是一个单机系统，所有的站点、数据库、文件都部署在一台服务器上。工程师每天的核心工作是CURD，浏览器端传过来一些数据，解析GET/POST/COOKIE中传过来的数据，拼装成一些CURD的sql语句访问数据库，数据库返回数据，拼装成页面，返回浏览器。相信很多创业团队的工程师，初期做的也是类似的工作。

58同城最初选择的是微软技术体系这条路：Windows、iis、SQL-Sever、C#

如果重新再来，我们可能会选择LAMP体系。

为什么选择LAMP？

LAMP无须编译，发布快速，功能强大，社区活跃，从前端+后端+数据库访问+业务逻辑处理全部可以搞定，并且开源免费，公司做大了也不会有人上门收钱（不少公司吃过亏）。现在大家如果再创业，强烈建议使用LAMP。

好架构是进化来的，不是设计来的（58架构演进）

初创阶段，工程师面临的主要问题：写CURD的sql语句很容易出错。

我们在这个阶段引进DAO和ORM，让工程师们不再直接面对CURD的sql语句，而是面对他们比较擅长的面向对象开发，极大的提高了编码效率，降低了出错率。

第二章：流量增加，数据库成为瓶颈

随着流量越来越大，老板不只要求“有一个可以看见的站点”，他希望网站能够正常访问，当然速度快点就更好了。

而此时系统面临问题是：流量的高峰期容易宕机，大量的请求会压到数据库上，数据库成为新的瓶颈，人多并行访问时站点非常卡。这时，我们的机器数量也从一台变成了多台，我们的系统成了所谓的（伪）“分布式架构”：

好架构是进化来的，不是设计来的（58架构演进）

我们使用了一些常见优化手段：

（1）动静分离，动态的页面通过Web-Server访问，静态的文件例如图片就放到单独的文件服务器上；
（2）读写分离，将落到数据库上的读写请求分派到不同的数据库服务器上；

互联网绝大部分的业务场景，都是读多写少。对58同城来说，绝大部分用户的需求是访问信息，搜索信息，只有少数的用户发贴。此时读取性能容易成为瓶颈，那么如何扩展整个站点架构的读性能呢？常用的方法是主从同步，增加从库。我们原来只有一个读数据库，现在有多个读数据库，就提高了读性能。

在这个阶段，系统的主要矛盾为“站点耦合+读写延时”，58同城是如何解决这两个问题的呢？

第一个问题是站点耦合。对58同城而言，典型业务场景是：类别聚合的主页，发布信息的发布页，信息聚合的列表页，帖子内容的详细页，原来这些系统都耦合在一个站点中，出现问题的时候，整个系统都会受到影响。

第二个问题是读写延时。数据库做了主从同步和读写分离之后，读写库之间数据的同步有一个延时，数据库数据量越大，从库越多时，延时越明显。对应到业务，有用户发帖子，马上去搜索可能搜索不到（着急的用户会再次发布相同的帖子）。

好架构是进化来的，不是设计来的（58架构演进）

要解决耦合的问题，最先想到的是针对核心业务做切分，工程师根据业务切分对系统也进行切分：我们将业务垂直拆分成了首页、发布页、列表页和详情页。

另外，我们在数据库层面也进行了垂直拆分，将单库数据量降下来，让读写延时得到缓解。

好架构是进化来的，不是设计来的（58架构演进）

同时，还使用了这些技术来优化系统和提高研发效率：

（1）对动态资源和静态资源进行拆分。对静态资源我们使用了CDN服务，用户就近访问，静态资源的访问速度得到很明显的提升；
（2）除此之外，我们还使用了MVC模式，擅长前端的工程师去做展示层，擅长业务逻辑的工程师就做控制层，擅长数据的工程师就做数据层，专人专用，研发效率和质量又进一步提高。

第三章：全面转型开源技术体系

流量越来越大，当流量达到百万甚至千万时，站点面临一个很大的问题就是性能和成本的折衷。上文提到58同城最初的技术选型是Windows，我们在这个阶段做了一次脱胎换骨的技术转型，全面转向开源技术：

（1）操作系统转型Linux
（2）数据库转型Mysql
（3）web服务器转型Tomcat
（4）开发语言转向了Java

其实，很多互联网公司在流量从小到大的过程中都经历过类似的转型，例如京东和淘宝。

随着用户量的增加，对站点可用性要求也越来越高，机器数也从最开始的几台上升到几百台。那么如何提供保证整个系统的可用性呢？首先，我们在业务层做了进一步的垂直拆分，同时引入了Cache，如下图所示：

好架构是进化来的，不是设计来的（58架构演进）

在架构上，我们抽象了一个相对独立的服务层，所有数据的访问都通过这个服务层统一来管理，上游业务线就像调用本地函数一样，通过RPC的框架来调用这个服务获取数据，服务层对上游屏蔽底层数据库与缓存的复杂性。

好架构是进化来的，不是设计来的（58架构演进）

除此之外，为了保证站点的高可用，我们使用了反向代理。

什么是代理？代理就是代表用户访问xxoo站点。

什么是反向代理？反向代理代表的是58网站，用户不用关注访问是58同城的哪台服务器，由反向代理来代表58同城。58同城通过反向代理，DNS轮询，LVS等技术，来保证接入层的高可用性。

另外，为了保证服务层和数据层的高可用，我们采用了冗余的方法，单点服务不可用，我们就冗余服务，单点数据不可用，我们就冗余数据。

这个阶段58同城进入了一个业务高速爆发期，短期内衍生出非常多的业务站点和服务。新增站点、新增服务每次都会做一些重复的事情，例如线程模型，消息队列，参数解析等等，于是，58同城就研发了自己的站点框架和服务框架，现在这两个框架也都已经开源：

（1）站点框架Argo： https://github.com/58code/Argo
（2）服务框架Gaea： https://github.com/58code/Gaea

这个阶段，为了进一步解耦系统，我们引入了配置中心、柔性服务和消息总线。

好架构是进化来的，不是设计来的（58架构演进）

引入配置中心，业务要访问任何一个服务，不需要在本地的配置文件中配置服务的ip list，而只需要访问配置中心。这种方式的扩展性非常好，如果有机器要下线，配置中心会反向通知上游订阅方，而不需要更新本地配置文件。

柔性服务是指当流量增加的时候，自动的扩展服务和站点。

消息总线也是一种解耦上下游“调用”关系常见的技术手段。

机器越来越多，此时很多系统层面的问题，靠“人肉”已经很难搞定，于是自动化变得越来越重要：自动化回归、自动化测试、自动化运维、自动化监控等等等等。

最后补充一点，这个阶段我们引入了不少智能化产品，比如智能推荐，主动推荐一些相关的数据，以增加58同城的PV；智能广告，通过一些智能的策略，让用户对广告的点击更多，增加同城的收入；智能搜索，在搜索的过程中加入一些智能的策略，提高用户的点击率，以增加58同城的PV。这些智能化产品的背后都由技术驱动。

第四章、进一步的挑战

现在，58同城的流量已经达到10亿的量级，架构上我们规划做一些什么样的事情呢，几个方向：

（1）业务服务化
（2）多架构模式
（3）平台化
（4）…

好架构是进化来的，不是设计来的（58架构演进）

第五章：小结

最后做一个简单的总结，网站在不同的阶段遇到的问题不一样，而解决这些问题使用的技术也不一样：

（1）流量小的时候，我们要提高开发效率，可以在早期要引入ORM，DAO；
（2）流量变大，可以使用动静分离、读写分离、主从同步、垂直拆分、CDN、MVC等方式不断提升网站的性能和研发效率；
（3）面对更大的流量时，通过垂直拆分、服务化、反向代理、开发框架（站点/服务）等等手段，可以不断提升高可用（研发效率）；
（4）在面对上亿级的流量时，通过配置中心、柔性服务、消息总线、自动化（回归，测试，运维，监控）来迎接新的挑战

互联网分层架构

【2020-12-02】沈剑
- 互联网分层架构的本质是数据移动，出处
- 为什么说，MapReduce，颠覆了互联网分层架构的本质？
- 缓存架构，到底设计些什么？
- “选redis还是memcache”，面试官究竟想考察啥？
图

上图是一个典型的互联网分层架构：

客户端层：典型调用方是browser或者APP
站点应用层：实现核心业务逻辑，从下游获取数据，对上游返回html或者json
数据-缓存层：加速访问存储
数据-数据库层：固化数据存储

如果实施了服务化，这个分层架构图可能是这样：

中间多了一个服务层。

同一个层次的内部，例如端上的APP，以及web-server，也都有进行MVC分层：

view层：展现
control层：逻辑
model层：数据

可以看到，每个工程师骨子里，都潜移默化的实施着分层架构。

那么，互联网分层架构的本质究竟是什么呢？

如果我们仔细思考会发现，不管是跨进程的分层架构，还是进程内的MVC分层，都是一个“数据移动”，然后“被处理”和“被呈现”的过程，归根结底一句话：互联网分层架构，是一个数据移动，处理，呈现的过程，其中数据移动是整个过程的核心。

如上图所示：

数据处理和呈现要CPU计算，CPU是固定不动的：

db/service/web-server都部署在固定的集群上
端上，不管是browser还是APP，也有固定的CPU处理

数据是移动的：

跨进程移动：数据从数据库和缓存里，转移到service层，到web-server层，到client层
同进程移动：数据从model层，转移到control层，转移到view层

数据要移动，所以有两个东西很重要：

数据传输的格式
数据在各层次的形态

先看数据传输的格式，即协议很重要：

service与db/cache之间，二进制协议/文本协议是数据传输的载体
web-server与service之间，RPC的二进制协议是数据传输的载体
client和web-server之间，http协议是数据传输的载体

再看数据在各层次的形态，以用户数据为例：

db层，数据是以“行”为单位存在的row(uid, name, age)
cache层，数据是以kv的形式存在的kv(uid -> User)
service层，会把row或者kv转化为对程序友好的User对象
web-server层，会把对程序友好的User对象转化为对http友好的json对象
client层：最终端上拿到的是json对象

结论：互联网分层架构的本质，是数据的移动。

为什么要说这个，这将会引出“分层架构演进”的核心原则与方法：

让上游更高效的获取与处理数据，复用
让下游能屏蔽数据的获取细节，封装

弄清楚这个原则与方法，再加上一些经验积累，就能回答网友经常在评论中提出的这些问题了：

是否需要引入DAO层，什么时机引入
是否需要服务化，什么时机服务化
是否需要抽取通用中台业务，什么时机抽取
是否需要前后端分离，什么时机分离

（网友们的这些提问，其实很难回答。在不了解业务发展阶段，业务规模，数据量并发量的情况下，妄下YES或NO的结论，本身就是不负责任的。）

更具体的分层架构演进细节，下一篇和大家细究。

总结

互联网分层架构的本质，是数据的移动
互联网分层架构中，数据的传输格式（协议）与数据在各层次的形态很重要
互联网分层架构演进的核心原则与方法：封装与复用

思考

哪一个系统的架构，不是“固定CPU，移动数据”，而是“固定数据，移动CPU”呢？

微服务

【2020-12-18】微服务入门这一篇就够了
【2021-5-23】微服务架构，精华
知乎：什么是微服务架构图

微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务元年；

微服务问题解答

四点问题,参考：微服务架构

1、客户端如何访问这些服务
- 后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。所以，一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway
2、每个服务之间如何通信
- 所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通信就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式：(1) 同步调用：①REST（JAX-RS，Spring Boot）②RPC（Thrift, Dubbo）(2) 异步消息调用(Kafka, Notify, MetaQ)
3、如此多的服务，如何实现？
- 每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。
4、服务挂了，如何解决？（备份方案，应急处理机制）
- ①重试机制 ②限流 ③熔断机制 ④负载均衡 ⑤降级（本地缓存）

微服务架构

六种常见的微服务架构设计模式，参考：微服务架构

1、聚合器微服务设计模式

这是一种最常见也最简单的设计模式：

聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步

发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。

2、代理微服务设计模式

这是聚合模式的一个变种，如下图所示：

在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。

3、链式微服务设计模式

这种模式在接收到请求后会产生一个经过合并的响应，如下图所示：

在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。

因此，服务调用链不宜过长，以免客户端长时间等待。

4、分支微服务设计模式

这种模式是聚合器模式的扩展，允许同时调用两个微服务链，如下图所示：

5、数据共享微服务设计模式

自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithic application）”时，SQL数据库反规范化可能会导致数据重复和不一致。

因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式，如下图所示：

在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。

6、异步消息传递微服务设计模式

虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应，如下图所示：

SOA和微服务的区别

1、SOA喜欢重用，微服务喜欢重写
- SOA的主要目的是为了企业各个系统更加容易地融合在一起。说到SOA不得不说ESB(EnterpriseService Bus)。 ESB是什么? 可以把ESB想象成一个连接所有企业级服务的脚手架。通过service broker，它可以把不同数据格式或模型转成canonical格式，把XML的输入转成CSV传给legacy服务，把SOAP 1.1服务转成 SOAP 1.2等等。它还可以把一个服务路由到另一个服务上，也可以集中化管理业务逻辑，规则和验证等等。它还有一个重要功能是消息队列和事件驱动的消息传递，比如把JMS服务转化成SOAP协议。各服务间可能有复杂的依赖关系。
- 微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然后单独布署。它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码，而是减少客户端和服务间的往来。API gateway模式不等同与Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。
2、SOA喜欢水平服务，微服务喜欢垂直服务
- SOA设计喜欢给服务分层(如Service Layers模式)。我们常常见到一个Entity服务层的设计，美其名曰Data Access Layer。这种设计要求所有的服务都通过这个Entity服务层来获取数据。这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。而每个微服务通常有它自己独立的data store。我们在拆分数据库时可以适当的做些去范式化(denormalization)，让它不需要依赖其他服务的数据。
- 微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。类似的功能可能针对手机有一个服务，针对机顶盒是另外一个服务。在SOA设计模式中这种情况通常会用到Multi-ChannelEndpoint的模式返回一个大而全的结果兼顾到所有的客户端的需求。
3、SOA喜欢自上而下，微服务喜欢自下而上
- SOA架构在设计开始时会先定义好服务合同(service contract)。它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，schema，等等。它使用Enterprise Inventory和Service Composition等方法来集中管理服务。 SOA架构通常会预先把每个模块服务接口都定义好。模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。

SOA架构适用于TOGAF之类的架构方法论。微服务则敏捷得多。只要用户用得到，就先把这个服务挖出来。然后针对性的，快速确认业务需求，快速开发迭代。

什么是微服务

csdn微服务架构ppt

单体应用

没有提出微服务的概念的“远古”年代，一个软件应用，往往会将应用所有功能都开发和打包在一起，那时候的一个B/S应用架构往往是这样的
- （1）B/S架构图
当用户访问量变大导致一台服务器无法支撑时怎么办呢？加服务器加负载均衡
- （2）B/S+负载均衡图
后来发现把静态文件独立出来，通过CDN等手段进行加速，可以提升应用的整体响应
- （3）B/S+前后端分离图
上面3种架构都还是单体应用，只是在部署方面进行了优化，所以避免不了单体应用的根本的缺点：
- 代码臃肿，应用启动时间长；（代码超过1G的项目都有！）
- 回归测试周期长，修复一个小小bug可能都需要对所有关键业务进行回归测试。
- 应用容错性差，某个小小功能的程序错误可能导致整个系统宕机；
- 伸缩困难，单体应用扩展性能时只能整个应用进行扩展，造成计算资源浪费。
- 开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护一套代码的话，代码merge复杂度急剧增加。
优点
- 架构简单
- 开发，测试，部署也简单
缺点
- 随着业务扩展，代码越来越复杂，代码质量参差不齐(开发人员的水平不一),会让你每次提交代码，修改每一个小bug都是心惊胆战的。
- 部署慢(由于单体架构，功能复杂) 能想像下一个来自200W+代码部署的速度 (15分钟)。
- 扩展成本高，根据单体架构图假设用户模块是一个CPU密集型的模块(涉及到大量的运算)那么我们需要替换更加牛逼的CPU，而我们的订单模块是一个IO密集模块（涉及大量的读写磁盘）,那我们需要替换更加牛逼的内存以及高效的磁盘。但是我们的单体架构上无法针对单个功能模块进行扩展，那么就需要替换更牛逼的CPU 更牛逼的内存更牛逼的磁盘价格蹭蹭的往上涨。
- 阻碍了新技术的发展。。。。。。比如我们的web架构模块从 struts2迁移到springboot，那么就会成为灾难性

单体架构与微服务架构

单体架构：一份代码包含了所有功能
微服务架构：
- 把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程，每个服务都能够单独部署，甚至可以拥有自己的数据库。

微服务

技术演进都是有迹可循的，任何新技术的出现都是为了解决原有技术无法解决的需求，所以，微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。
在微服务架构之前还有一个概念：SOA（Service-Oriented Architecture）- 面向服务的体系架构。
SOA只是一个架构模型的方法论，并不是一个明确而严谨的架构标准，只是后面很多人将SOA与The Open Group的SOA参考模型等同了，认为严格按照TOG-SOA标准的才算真正的SOA架构。SOA就已经提出的面向服务的架构思想，所以微服务应该算是SOA的一种演进吧。
撇开架构先不说，什么样的服务才算微服务呢？
- 单一职责的。一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。
- 面向服务的。将自己的业务能力封装并对外提供服务，这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力。
满足以上两点就可以认为典型的微服务。

优点：

①：每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应用，可能改几行代码需要了解整个系统)。
②：开发简单，一个服务只干一个事情。（加入你做支付服务，你只要了解支付相关代码就可以了。
③：微服务能够被2-5个人的小团队开发，提高效率。
④：按需伸缩。
⑤：前后段分离, 作为java开发人员，我们只要关系后端接口的安全性以及性能，不要去关注页面的人机交互(H5工程师)根据前后端接口协议，根据入参，返回json的回参。
⑥：一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据库。

缺点：

①：增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千个war包 (k8s+docker+jenkis )。
②：服务之间相互调用，增加通信成本。
③：数据一致性问题(分布式事物问题)。
④：系能监控等,问题定位等。

微服务的适用场景

合适：
- ①：大型复杂的项目…(来自单体架构200W行代码的恐惧)。
- ②：快速迭代的项目…(来自一天一版的恐惧)。
- ③：并发高的项目…(考虑弹性伸缩扩容的恐惧)。
不合适：
- ①：业务稳定，就是修修bug ，改改数据。
- ②：迭代周期长发版频率一二个月一次。

微服务典型架构

微服务架构，核心是为了解决应用微服务化之后的服务治理问题。
应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单
解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心，微服务架构就变成下面这样了：
以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：
上面是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：
- 通过熔断、限流等机制保证高可用；
- 微服务之间调用的负载均衡；
- 分布式事务（2PC、3PC、TCC、LCN等）；
- 服务调用链跟踪等等

一文详解微服务架构

一文详解微服务架构，或地址

本文将介绍微服务架构和相关的组件，介绍他们是什么以及为什么要使用微服务架构和这些组件。本文侧重于简明地表达微服务架构的全局图景，因此不会涉及具体如何使用组件等细节。

要理解微服务，首先要先理解不是微服务的那些。通常跟微服务相对的是单体应用，即将所有功能都打包成在一个独立单元的应用程序。从单体应用到微服务并不是一蹴而就的，这是一个逐渐演变的过程。本文将以一个网上超市应用为例来说明这一过程。

最初的需求

几年前，小明和小皮一起创业做网上超市。小明负责程序开发，小皮负责其他事宜。当时互联网还不发达，网上超市还是蓝海。只要功能实现了就能随便赚钱。所以他们的需求很简单，只需要一个网站挂在公网，用户能够在这个网站上浏览商品、购买商品；另外还需一个管理后台，可以管理商品、用户、以及订单数据。

我们整理一下功能清单：

网站：

用户注册、登录功能
商品展示
下单

管理后台：

用户管理
商品管理
订单管理

由于需求简单，小明左手右手一个慢动作，网站就做好了。管理后台出于安全考虑，不和网站做在一起，小明右手左手慢动作重播，管理网站也做好了。总体架构图如下：

小明挥一挥手，找了家云服务部署上去，网站就上线了。上线后好评如潮，深受各类肥宅喜爱。小明小皮美滋滋地开始躺着收钱。

随着业务发展……

好景不长，没过几天，各类网上超市紧跟着拔地而起，对小明小皮造成了强烈的冲击。

在竞争的压力下，小明小皮决定开展一些营销手段：

开展促销活动。比如元旦全场打折，春节买二送一，情人节狗粮优惠券等等。
拓展渠道，新增移动端营销。除了网站外，还需要开发移动端APP，微信小程序等。
精准营销。利用历史数据对用户进行分析，提供个性化服务。
……

这些活动都需要程序开发的支持。小明拉了同学小红加入团队。小红负责数据分析以及移动端相关开发。小明负责促销活动相关功能的开发。

因为开发任务比较紧迫，小明小红没有好好规划整个系统的架构，随便拍了拍脑袋，决定把促销管理和数据分析放在管理后台里，微信和移动端APP另外搭建。通宵了几天后，新功能和新应用基本完工。这时架构图如下：

这一阶段存在很多不合理的地方：

网站和移动端应用有很多相同业务逻辑的重复代码。
数据有时候通过数据库共享，有时候通过接口调用传输。接口调用关系杂乱。
单个应用为了给其他应用提供接口，渐渐地越改越大，包含了很多本来就不属于它的逻辑。应用边界模糊，功能归属混乱。
管理后台在一开始的设计中保障级别较低。加入数据分析和促销管理相关功能后出现性能瓶颈，影响了其他应用。
数据库表结构被多个应用依赖，无法重构和优化。
所有应用都在一个数据库上操作，数据库出现性能瓶颈。特别是数据分析跑起来的时候，数据库性能急剧下降。
开发、测试、部署、维护愈发困难。即使只改动一个小功能，也需要整个应用一起发布。有时候发布会不小心带上了一些未经测试的代码，或者修改了一个功能后，另一个意想不到的地方出错了。为了减轻发布可能产生的问题的影响和线上业务停顿的影响，所有应用都要在凌晨三四点执行发布。发布后为了验证应用正常运行，还得盯到第二天白天的用户高峰期……
团队出现推诿扯皮现象。关于一些公用的功能应该建设在哪个应用上的问题常常要争论很久，最后要么干脆各做各的，或者随便放个地方但是都不维护。

尽管有着诸多问题，但也不能否认这一阶段的成果：快速地根据业务变化建设了系统。不过紧迫且繁重的任务容易使人陷入局部、短浅的思维方式，从而做出妥协式的决策。在这种架构中，每个人都只关注在自己的一亩三分地，缺乏全局的、长远的设计。长此以往，系统建设将会越来越困难，甚至陷入不断推翻、重建的循环。

是时候做出改变了

幸好小明和小红是有追求有理想的好青年。意识到问题后，小明和小红从琐碎的业务需求中腾出了一部分精力，开始梳理整体架构，针对问题准备着手改造。

要做改造，首先你需要有足够的精力和资源。如果你的需求方（业务人员、项目经理、上司等）很强势地一心追求需求进度，以致于你无法挪出额外的精力和资源的话，那么你可能无法做任何事……

在编程的世界中，最重要的便是抽象能力。微服务改造的过程实际上也是个抽象的过程。小明和小红整理了网上超市的业务逻辑，抽象出公用的业务能力，做成几个公共服务：

用户服务
商品服务
促销服务
订单服务
数据分析服务

各个应用后台只需从这些服务获取所需的数据，从而删去了大量冗余的代码，就剩个轻薄的控制层和前端。这一阶段的架构如下：

这个阶段只是将服务分开了，数据库依然是共用的，所以一些烟囱式系统的缺点仍然存在：

数据库成为性能瓶颈，并且有单点故障的风险。
数据管理趋向混乱。即使一开始有良好的模块化设计，随着时间推移，总会有一个服务直接从数据库取另一个服务的数据的现象。
数据库表结构可能被多个服务依赖，牵一发而动全身，很难调整。

如果一直保持共用数据库的模式，则整个架构会越来越僵化，失去了微服务架构的意义。因此小明和小红一鼓作气，把数据库也拆分了。所有持久化层相互隔离，由各个服务自己负责。另外，为了提高系统的实时性，加入了消息队列机制。架构如下：

完全拆分后各个服务可以采用异构的技术。比如数据分析服务可以使用数据仓库作为持久化层，以便于高效地做一些统计计算；商品服务和促销服务访问频率比较大，因此加入了缓存机制等。

还有一种抽象出公共逻辑的方法是把这些公共逻辑做成公共的框架库。这种方法可以减少服务调用的性能损耗。但是这种方法的管理成本非常高昂，很难保证所有应用版本的一致性。
数据库拆分也有一些问题和挑战：比如说跨库级联的需求，通过服务查询数据颗粒度的粗细问题等。但是这些问题可以通过合理的设计来解决。总体来说，数据库拆分是一个利大于弊的。

微服务架构还有一个技术外的好处，它使整个系统的分工更加明确，责任更加清晰，每个人专心负责为其他人提供更好的服务。在单体应用的时代，公共的业务功能经常没有明确的归属。最后要么各做各的，每个人都重新实现了一遍；要么是随机一个人（一般是能力比较强或者比较热心的人）做到他负责的应用里面。在后者的情况下，这个人在负责自己应用之外，还要额外负责给别人提供这些公共的功能——而这个功能本来是无人负责的，仅仅因为他能力较强/比较热心，就莫名地背锅（这种情况还被美其名曰能者多劳）。结果最后大家都不愿意提供公共的功能。长此以往，团队里的人渐渐变得各自为政，不再关心全局的架构设计。

从这个角度上看，使用微服务架构同时也需要组织结构做相应的调整。所以说做微服务改造需要管理者的支持。

改造完成后，小明和小红分清楚各自的锅。两人十分满意，一切就像是麦克斯韦方程组一样漂亮完美。然而……

没有银弹

春天来了，万物复苏，又到了一年一度的购物狂欢节。眼看着日订单数量蹭蹭地上涨，小皮小明小红喜笑颜开。可惜好景不长，乐极生悲，突然嘣的一下，系统挂了。

以往单体应用，排查问题通常是看一下日志，研究错误信息和调用堆栈。而微服务架构整个应用分散成多个服务，定位故障点非常困难。小明一个台机器一台机器地查看日志，一个服务一个服务地手工调用。经过十几分钟的查找，小明终于定位到故障点：促销服务由于接收的请求量太大而停止响应了。其他服务都直接或间接地会调用促销服务，于是也跟着宕机了。在微服务架构中，一个服务故障可能会产生雪崩效用，导致整个系统故障。其实在节前，小明和小红是有做过请求量评估的。按照预计，服务器资源是足以支持节日的请求量的，所以肯定是哪里出了问题。不过形势紧急，随着每一分每一秒流逝的都是白花花的银子，因此小明也没时间排查问题，当机立断在云上新建了几台虚拟机，然后一台一台地部署新的促销服务节点。几分钟的操作后，系统总算是勉强恢复正常了。整个故障时间内估计损失了几十万的销售额，三人的心在滴血……

事后，小明简单写了个日志分析工具（量太大了，文本编辑器几乎打不开，打开了肉眼也看不过来），统计了促销服务的访问日志，发现在故障期间，商品服务由于代码问题，在某些场景下会对促销服务发起大量请求。这个问题并不复杂，小明手指抖一抖，修复了这个价值几十万的Bug。

问题是解决了，但谁也无法保证不会再发生类似的其他问题。微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。微服务架构虽然解决了旧问题，也引入了新的问题：

微服务架构整个应用分散成多个服务，定位故障点非常困难。
稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出现的。
服务数量非常多，部署、管理的工作量很大。
开发方面：如何保证各个服务在持续开发的情况下仍然保持协同合作。
测试方面：服务拆分后，几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。

小明小红痛定思痛，决心好好解决这些问题。对故障的处理一般从两方面入手，一方面尽量减少故障发生的概率，另一方面降低故障造成的影响。

监控 - 发现故障的征兆

在高并发分布式的场景下，故障经常是突然间就雪崩式爆发。所以必须建立完善的监控体系，尽可能发现故障的征兆。

微服务架构中组件繁多，各个组件所需要监控的指标不同。比如Redis缓存一般监控占用内存值、网络流量，数据库监控连接数、磁盘空间，业务服务监控并发数、响应延迟、错误率等。因此如果做一个大而全的监控系统来监控各个组件是不大现实的，而且扩展性会很差。一般的做法是让各个组件提供报告自己当前状态的接口（metrics接口），这个接口输出的数据格式应该是一致的。然后部署一个指标采集器组件，定时从这些接口获取并保持组件状态，同时提供查询服务。最后还需要一个UI，从指标采集器查询各项指标，绘制监控界面或者根据阈值发出告警。

大部分组件都不需要自己动手开发，网络上有开源组件。小明下载了RedisExporter和MySQLExporter，这两个组件分别提供了Redis缓存和MySQL数据库的指标接口。微服务则根据各个服务的业务逻辑实现自定义的指标接口。然后小明采用Prometheus作为指标采集器，Grafana配置监控界面和邮件告警。这样一套微服务监控系统就搭建起来了：

定位问题 - 链路跟踪

在微服务架构下，一个用户的请求往往涉及多个内部服务调用。为了方便定位问题，需要能够记录每个用户请求时，微服务内部产生了多少服务调用，及其调用关系。这个叫做链路跟踪。

我们用一个Istio文档里的链路跟踪例子来看看效果：

图片来自Istio文档

从图中可以看到，这是一个用户访问productpage页面的请求。在请求过程中，productpage服务顺序调用了details和reviews服务的接口。而reviews服务在响应过程中又调用了ratings的接口。整个链路跟踪的记录是一棵树：

要实现链路跟踪，每次服务调用会在HTTP的HEADERS中记录至少记录四项数据：

traceId：traceId标识一个用户请求的调用链路。具有相同traceId的调用属于同一条链路。
spanId：标识一次服务调用的ID，即链路跟踪的节点ID。
parentId：父节点的spanId。
requestTime & responseTime：请求时间和响应时间。

另外，还需要调用日志收集与存储的组件，以及展示链路调用的UI组件。

以上只是一个极简的说明，关于链路跟踪的理论依据可详见Google的Dapper

了解了理论基础后，小明选用了Dapper的一个开源实现Zipkin。然后手指一抖，写了个HTTP请求的拦截器，在每次HTTP请求时生成这些数据注入到HEADERS，同时异步发送调用日志到Zipkin的日志收集器中。这里额外提一下，HTTP请求的拦截器，可以在微服务的代码中实现，也可以使用一个网络代理组件来实现（不过这样子每个微服务都需要加一层代理）。

链路跟踪只能定位到哪个服务出现问题，不能提供具体的错误信息。查找具体的错误信息的能力则需要由日志分析组件来提供。

分析问题 - 日志分析

日志分析组件应该在微服务兴起之前就被广泛使用了。即使单体应用架构，当访问数变大、或服务器规模增多时，日志文件的大小会膨胀到难以用文本编辑器进行访问，更糟的是它们分散在多台服务器上面。排查一个问题，需要登录到各台服务器去获取日志文件，一个一个地查找（而且打开、查找都很慢）想要的日志信息。

因此，在应用规模变大时，我们需要一个日志的“搜索引擎”。以便于能准确的找到想要的日志。另外，数据源一侧还需要收集日志的组件和展示结果的UI组件：

小明调查了一下，使用了大名鼎鼎地ELK日志分析组件。ELK是Elasticsearch、Logstash和Kibana三个组件的缩写。

Elasticsearch：搜索引擎，同时也是日志的存储。
Logstash：日志采集器，它接收日志输入，对日志进行一些预处理，然后输出到Elasticsearch。
Kibana：UI组件，通过Elasticsearch的API查找数据并展示给用户。

最后还有一个小问题是如何将日志发送到Logstash。一种方案是在日志输出的时候直接调用Logstash接口将日志发送过去。这样一来又（咦，为啥要用“又”）要修改代码……于是小明选用了另一种方案：日志仍然输出到文件，每个服务里再部署个Agent扫描日志文件然后输出给Logstash。

网关 - 权限控制，服务治理

拆分成微服务后，出现大量的服务，大量的接口，使得整个调用关系乱糟糟的。经常在开发过程中，写着写着，忽然想不起某个数据应该调用哪个服务。或者写歪了，调用了不该调用的服务，本来一个只读的功能结果修改了数据……

为了应对这些情况，微服务的调用需要一个把关的东西，也就是网关。在调用者和被调用者中间加一层网关，每次调用时进行权限校验。另外，网关也可以作为一个提供服务接口文档的平台。

使用网关有一个问题就是要决定在多大粒度上使用：最粗粒度的方案是整个微服务一个网关，微服务外部通过网关访问微服务，微服务内部则直接调用；最细粒度则是所有调用，不管是微服务内部调用或者来自外部的调用，都必须通过网关。折中的方案是按照业务领域将微服务分成几个区，区内直接调用，区间通过网关调用。

由于整个网上超市的服务数量还不算特别多，小明采用的最粗粒度的方案：

服务注册于发现 - 动态扩容

前面的组件，都是旨在降低故障发生的可能性。然而故障总是会发生的，所以另一个需要研究的是如何降低故障产生的影响。

最粗暴的（也是最常用的）故障处理策略就是冗余。一般来说，一个服务都会部署多个实例，这样一来能够分担压力提高性能，二来即使一个实例挂了其他实例还能响应。

冗余的一个问题是使用几个冗余？这个问题在时间轴上并没有一个切确的答案。根据服务功能、时间段的不同，需要不同数量的实例。比如在平日里，可能4个实例已经够用；而在促销活动时，流量大增，可能需要40个实例。因此冗余数量并不是一个固定的值，而是根据需要实时调整的。

一般来说新增实例的操作为：

部署新实例
将新实例注册到负载均衡或DNS上

操作只有两步，但如果注册到负载均衡或DNS的操作为人工操作的话，那事情就不简单了。想想新增40个实例后，要手工输入40个IP的感觉……

解决这个问题的方案是服务自动注册与发现。首先，需要部署一个服务发现服务，它提供所有已注册服务的地址信息的服务。DNS也算是一种服务发现服务。然后各个应用服务在启动时自动将自己注册到服务发现服务上。并且应用服务启动后会实时（定期）从服务发现服务同步各个应用服务的地址列表到本地。服务发现服务也会定期检查应用服务的健康状态，去掉不健康的实例地址。这样新增实例时只需要部署新实例，实例下线时直接关停服务即可，服务发现会自动检查服务实例的增减。

服务发现还会跟客户端负载均衡配合使用。由于应用服务已经同步服务地址列表在本地了，所以访问微服务时，可以自己决定负载策略。甚至可以在服务注册时加入一些元数据（服务版本等信息），客户端负载则根据这些元数据进行流量控制，实现A/B测试、蓝绿发布等功能。

服务发现有很多组件可以选择，比如说Zookeeper 、Eureka、Consul、Etcd等。不过小明觉得自己水平不错，想炫技，于是基于Redis自己写了一个……

熔断、服务降级、限流

熔断

当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。所以当多次访问一个服务失败时，应熔断，标记该服务已停止工作，直接返回错误。直至该服务恢复正常后再重新建立连接。

图片来自《微服务设计》

服务降级

当下游服务停止工作后，如果该服务并非核心业务，则上游服务应该降级，以保证核心业务不中断。比如网上超市下单界面有一个推荐商品凑单的功能，当推荐模块挂了后，下单功能不能一起挂掉，只需要暂时关闭推荐功能即可。

限流

一个服务挂掉后，上游服务或者用户一般会习惯性地重试访问。这导致一旦服务恢复正常，很可能因为瞬间网络流量过大又立刻挂掉，在棺材里重复着仰卧起坐。因此服务需要能够自我保护——限流。限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请求。另外，也可以考虑分区限流。仅拒绝来自产生大量请求的服务的请求。例如商品服务和订单服务都需要访问促销服务，商品服务由于代码问题发起了大量请求，促销服务则只限制来自商品服务的请求，来自订单服务的请求则正常响应。

测试

微服务架构下，测试分为三个层次：

端到端测试：覆盖整个系统，一般在用户界面机型测试。
服务测试：针对服务接口进行测试。
单元测试：针对代码单元进行测试。

三种测试从上到下实施的容易程度递增，但是测试效果递减。端到端测试最费时费力，但是通过测试后我们对系统最有信心。单元测试最容易实施，效率也最高，但是测试后不能保证整个系统没有问题。

由于端到端测试实施难度较大，一般只对核心功能做端到端测试。一旦端到端测试失败，则需要将其分解到单元测试：则分析失败原因，然后编写单元测试来重现这个问题，这样未来我们便可以更快地捕获同样的错误。

服务测试的难度在于服务会经常依赖一些其他服务。这个问题可以通过Mock Server解决：

单元测试大家都很熟悉了。我们一般会编写大量的单元测试（包括回归测试）尽量覆盖所有代码。

微服务框架

指标接口、链路跟踪注入、日志引流、服务注册发现、路由规则等组件以及熔断、限流等功能都需要在应用服务上添加一些对接代码。如果让每个应用服务自己实现是非常耗时耗力的。基于DRY的原则，小明开发了一套微服务框架，将与各个组件对接的代码和另外一些公共代码抽离到框架中，所有的应用服务都统一使用这套框架进行开发。

使用微服务框架可以实现很多自定义的功能。甚至可以将程序调用堆栈信息注入到链路跟踪，实现代码级别的链路跟踪。或者输出线程池、连接池的状态信息，实时监控服务底层状态。

使用统一的微服务框架有一个比较严重的问题：框架更新成本很高。每次框架升级，都需要所有应用服务配合升级。当然，一般会使用兼容方案，留出一段并行时间等待所有应用服务升级。但是如果应用服务非常多时，升级时间可能会非常漫长。并且有一些很稳定几乎不更新的应用服务，其负责人可能会拒绝升级……因此，使用统一微服务框架需要完善的版本管理方法和开发管理规范。

另一条路 - Service Mesh

另一种抽象公共代码的方法是直接将这些代码抽象到一个反向代理组件。每个服务都额外部署这个代理组件，所有出站入站的流量都通过该组件进行处理和转发。这个组件被称为Sidecar。

Sidecar不会产生额外网络成本。Sidecar会和微服务节点部署在同一台主机上并且共用相同的虚拟网卡。所以sidecar和微服务节点的通信实际上都只是通过内存拷贝实现的。

图片来自：Pattern: Service Mesh

Sidecar只负责网络通信。还需要有个组件来统一管理所有sidecar的配置。在Service Mesh中，负责网络通信的部分叫数据平面（data plane），负责配置管理的部分叫控制平面（control plane）。数据平面和控制平面构成了Service Mesh的基本架构。

图片来自：Pattern: Service Mesh

Sevice Mesh相比于微服务框架的优点在于它不侵入代码，升级和维护更方便。它经常被诟病的则是性能问题。即使回环网络不会产生实际的网络请求，但仍然有内存拷贝的额外成本。另外有一些集中式的流量处理也会影响性能。

结束、也是开始

微服务不是架构演变的终点。往细走还有Serverless、FaaS等方向。另一方面也有人在唱合久必分分久必合，重新发现单体架构…… 不管怎样，微服务架构的改造暂时告一段落了。小明满足地摸了摸日益光滑的脑袋，打算这个周末休息一下约小红喝杯咖啡。

微服务框架

目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo（或者DubboX）、腾讯的Tar，但是Dubbo那两年的停更严重打击了开发人员对它的信心，Spring Cloud已经逐渐成为主流
- spring cloud platform：国内首个Spring Cloud微服务化RBAC的管理平台，核心采用Spring Boot 2.4、Spring Cloud 2020.0.0 & Alibaba，前端采用d2-admin中台框架。github地址，gitee地址，集成d2admin中台化前端，利用Spring Boot Admin 来监控各个独立Service的运行状态；利用Hystrix Dashboard来实时查看接口的运行状态和调用频率等,基于Nacos来实现的服务注册与调用，在Spring Cloud中使用Feign,集成阿里Sentinel进行接口流量控制，通过熔断和降级处理避免服务之间的调用“雪崩”。模块关系
- Tars：TARS是腾讯使用十年的微服务开发框架，目前支持C++、Java、PHP、Node.js、Go语言。该开源项目为用户提供了涉及到开发、运维、以及测试的一整套微服务平台PaaS解决方案，帮助一个产品或者服务快速开发、部署、测试、上线。目前该框架应用在腾讯各大核心业务，基于该框架部署运行的服务节点规模达到数十万。参考：tars的rpc源码解析
- cppcloud：官方文档，Demo，Java开发分布式微服务是方便了，然而SpringCloud提供java之外的接入文档或sdk却非常少，国内更加少了；微服务不是提昌各类的开发者都能参与进来看发整个系统的某一块服务吗，譬如有关业务计算的让cpp、golang开发，展示的让py开发；虽然Netflix说SpringCloud各个接口是Restful，但学到用起来的成本个人觉得还是很高。CppCloud 目的就是快速构建分布式服务之余，可以方便国内不同语言的开发者参与微服务的开发，而不仅限java；本项目核心服务（cppcloud_serv）采用c++开发，支持分布式部署，对外提供tcp服务；外部各应用接入时可以采用原生tcp协议接入、sdk接入、http间接接入；sdk方面目前开发了c++和python，由于一个人精力有限，其他的sdk暂时还未开发出来。
Spring Cloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面，以下列出了Spring Cloud一些常用组件：
Python微服务框架nameko的简单使用
基于 Go 语言的微服务框架 Jupiter
【2021-5-21】微服务分布式框架多语言代码示例，CppCloud gitee地址

下一代微服务

目前网上很多说是下一代微服务架构就是Service Mesh，Service Mesh主流框架有Linkerd和Istio，其中Istio有大厂加持所以呼声更高。

架构设计&演进-Arch Evolution

总结

架构

如何画架构图

UML图

客户端 vs 服务端

C/S 客户端/服务端 – 两层架构

B/S 浏览器/服务器 – 三层架构

B/S vs C/S

客户端、服务端分工

架构整洁之道

架构设计的OKR

编程范式

什么是好架构

如何设计架构

数据架构

DAO

MVC——Flask

MTV——Django

架构演进

1.单台服务器 + 数据库

2. 增加一个反向代理

3.引入负载均衡器

4. 扩展数据库

5. 微服务

6. 缓存和内容分发网络(CDN)

7. 消息队列

8.分片，分片，还是分片

9. 对负载均衡器进行负载均衡

Cloud Computing / Serverless

淘宝架构演进

1. 概述

2. 基本概念

3. 架构演进

3.1 单机架构

3.2 第一次演进：Tomcat与数据库分开部署

3.3 第二次演进：引入本地缓存和分布式缓存

3.4 第三次演进：引入反向代理实现负载均衡

3.5 第四次演进：数据库读写分离

3.6 第五次演进：数据库按业务分库

3.7 第六次演进：把大表拆分为小表

3.8 第七次演进：使用LVS或F5来使多个Nginx负载均衡

3.9 第八次演进：通过DNS轮询实现机房间的负载均衡

3.10 第九次演进：引入NoSQL数据库和搜索引擎等技术

3.11 第十次演进：大应用拆分为小应用

3.12 第十一次演进：复用的功能抽离成微服务

3.13 第十二次演进：引入企业服务总线ESB屏蔽服务接口的访问差异

3.14 第十三次演进：引入容器化技术实现运行环境隔离与动态服务管理

3.15 第十四次演进：以云平台承载系统

4. 架构设计总结

58架构

架构演进

第一章：建站之初

第二章：流量增加，数据库成为瓶颈

第三章：全面转型开源技术体系

第四章、进一步的挑战

第五章：小结

互联网分层架构

微服务

微服务问题解答

微服务架构

1、聚合器微服务设计模式

2、代理微服务设计模式

3、链式微服务设计模式

4、分支微服务设计模式

5、数据共享微服务设计模式

6、异步消息传递微服务设计模式

SOA和微服务的区别

什么是微服务

单体应用

微服务

微服务典型架构

一文详解微服务架构

熔断

服务降级

限流

微服务框架

下一代微服务

结束

Share