这是我参与「第四届青训营」笔记创作活动的第12天

架构演进的例子

孕育期

做一个信息流产品，可以无限刷的列表

• 首先，需要实现一个列表，支持上下滑动
• 然后，每次滑动，都需要请求服务端数据
• 接着，列表的每一项都需要响应点击操作
• ......

婴儿期

产品功能开始变多，需要拆分模块

• 首先，需要支持图文内容的组合混排显示
• 接着，需要引入账号体系，用户注册登录
• 然后，用户可以收藏感兴趣的内容并分享
• ......
• 继续，场景越来越多，拆分网络和多线程
• ......

学步期

业务场景变多，需要拆分业务

• 首先，支持用户发布文章，并给予奖励·接着，视频这个重要的内容也需要支持
• 然后，不同业务之间越做越大需要拆分
• ......
• 继续，拆分出视频业务，架构自成体系
• ......
• 继续，拆分出中台业务，供多业务使用
• ......

表现层： 接收用户输入，获取数据，呈现界面

业务层： 处理业务数据，数据流转，安全检查

持久层： 提供数据的增删改查能力

存储层： 按照特定的格式存储数据

优点

• 结构简单清晰，易于理解和管控
• 层级关系适合不同技能人员分工

缺点

• 对层级管控要求严格，灵活性低
• 为了解耦容易拆分出很多中间层

青春期

不同业务和模块混合，需要解耦

• 首先，需要约定模块可以对外提供的能力
• 接着，模块之间需要遵循相同的调用方式
• 然后，旧的模块需要按照相同标准来改造
• ......
• 继续，使用方不应该直接依赖于实现方
• ......

事件驱动架构

事件Event： 一个消息，譬如触摸了屏幕、点击了按钮

事件处理器Processor： 事件的实际消费者，对关注的消息进行订阅，消息处理的过程很灵活，可以在当前处理器“吞”掉一个消息，也可以继续将消息交由其他消息队列处理(责任链)

事件队列Event Channel： 消息队列，事件将以消息的形式发布到队列中，并设计特定的派发机制来处理队列中的消息

优点

• 适用广泛，容易扩展出不同变种
• 性能较好，支持消息的异步处理

缺点

• 缺少约束，消息处理器容器膨胀
• 处理链路容易变长，理解成本高

壮年期

业务变得更加内聚，需要灵活插拔

• 首先，扫一扫等能力不是所有场景都需要
• 接着，视频的子能力可以拆解后按需使用
• 然后，越来越多的业务想动态化发布产物
• ……
• 继续，动态化发布引入很多问题需要调优
• ……

微内核架构

宿主容器： Core System，一般不包含具体业务逻辑，而是从中抽象出模型，相当于一个运行环境，供不同业务以插件的形式在其中运行

插件： Plug-in Component，具体的业务实现，通过一定的技术手段挂载到宿主容器中，插件一般可以访问宿主的资源

优点

• 高扩展性，需要什么就开发什么
• 插件隔离，能够简化业务耦合度

缺点

• 对宿主容器的要求很高，且宿主不易扩展
• 插件的注册和通信机制通常比较复杂

稳定期

用户规模和团队稳定，历史包袱重

• 首先，经过前期快速发展已经积累了大量历史包袱
• 接着，需要深入了解业务才能设计出更合理的架构
• 然后，很多改动牵一发动全局，代码被迫变得更差
• ......
• 继续，新旧技术栈共存，版本依赖冲突，冗余代码
• ......

微服务架构

请求接入： 服务使用方发起请求，请求以一定的方式(可以直接调用，也可以跨进程调用)发送到服务注册中心，等待请求的处理

服务调度： Broker，将服务请求调度到对应的微服务节点上进行处理

微服务： Service Component，一个高度内聚的模块集合，对外暴露服务接口。每一个微服务都是独立的，分别向服务注册中心注册自身所能提供的服务接口

优点

• 健壮性好，单个服务不影响全局
• 服务隔离，服务之间互不相耦合

缺点

• 容器出现服务数量腹胀难以管控
• 服务发现和通信需要额外的成本

贵族期

复用、重构、规范、减负

对抗架构衰老，从我做起

官僚期

人们相互甩锅、代码混乱无序

不同形态的架构

架构演进	核心思想	优点	缺点
单体架构	快速组织界面交互、业务逻辑和数据之间的关系	快速成型、管理简单	依赖复杂、单点失效
分离架构	分而治之。拆分方式多样，譬如:按业务拆分(视频、图文、搜索等);或者按技术拆分(MVC、MVP、MVVM)	业务分层更清晰、组件复用	强制遵循规范、业务依旧耦合
服务化架构	设立业务之间的接口契约	业务解耦更内聚	服务数量膨胀
微内核架构	配套插件注册和发现机制，业务动态发布	服务隔离可插拔、局部失效影响可控	管理成本高、调用链路长
领域驱动设计(DDD)	战略设计从业务视角出发，建立业务领域模型。战术设计从技术视角出发，侧重于技术实现	解决复杂业务问题、架构随着业务发展	需成熟的团队、经验高度抽象

架构随业务发展由简单变得复杂是规律

没必要最初用复杂架构来解决简单问题

需要用规范持续重构来对抗代码的腐朽

成为优秀架构师

越是前面越难

定义问题 → 确定架构 → 方案落地 → 结果复盘

认清问题-分类

架构的问题是盘根错节的，将所有问题放在一起，就有轻重缓急之分，就有类别之分

区分问题的类别，就能在一定的边界内，匹配上对应的人来解决问题

认清问题-分级

挑战、问题、手段这些经常混为一谈，哪些是挑战?哪些是问题?那些是手段?

其实这些都是一回事，就是矛盾，只是不同场景下，矛盾所在的层级不同

认清问题-问题背后的问题

我们不能只局限于问题本身，还需要看到问题背后的问题，然后才能更容易找到更多的解决方案。

勤于编码

后记

通过今天课程的学习，了解了架构演进的规律，以及如何成为一名优秀的架构师，对我将来职业的发展很有帮助。