架构随笔 #

← 返回专题记录

演进 #

单体时代（巨石系统） #

分层，分模块，核心进程内通信。简单高效，损失模块的自治和隔离能力。最大的问题是容错性低。

• 烟囱式系统
• 微内核架构
• 事件驱动架构（优势在松散耦合、高可拓展性；劣势在于由于这种松散和可拓展性带来的系统复杂度提升）

SOA时代 #

更具体：

• 松散耦合
• 注册
• 发现
• 治理
• 隔离
• 编排

SOAP协议族，ESB 强管道。

更系统：

• 定义了整个企业的规范，甚至包括需求定义

微服务架构（Microservices） #

微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。
各个服务可以采用不同的编程语言、不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。

微服务的目的 #

微服务的目的是有效地拆分应用，实现敏捷开发和部署。

康威定律 #

系统的架构趋同于组织的沟通结构。

治理（Governance） #

治理就是让产品能够符合预期地稳定运行，并能够持续保持在一定的质量水平上。

9个核心 #

• 围绕业务能力构建（Organized around Business Capability）
• 分散治理（Decentralized Governance）
• 通过服务来实现独立自治的组件（Componentization via Services）
• 产品化思维（Products not Projects）
• 数据去中心化（Decentralized Data Management）
• 强终端弱管道（Smart Endpoint and Dumb Pipe）
• 容错性设计（Design for Failure）
• 演进式设计（Evolutionary Design）
• 基础设施自动化（Infrastructure Automation）

微服务关注点 #

• 高性能
• 高可用
• 高并发
• 高安全
• 可观测

1. 如何通信

   • 网关接入
   • 服务间通信，RPC

2. 如何治理

   • 服务发现、注册中心、配置中心
   • 事件日志：日志输出、收集缓冲 Kafka、加工聚合、存储查询 ELK / EFK
   • 链路追踪：追踪跨度、数据收集、追踪规范化 OpenTelemetry
   • 聚合度量：指标度量是手段，最终目的是做分析和预警 Prometheus

3. 如何部署

4. 如何容错

   • LB 均衡
   • 降级、熔断
   • k8s 弹性伸缩、自愈

后微服务时代（Cloud Native）云原生 #

从软件层面独力应对微服务架构问题，发展到软、硬一体，合力应对架构问题的时代，此即为“后微服务时代”。

微服务时代就强调的问题：

• 服务化
• 可观测
• 过程自动化
• 持续演进

云原生的新挑战：

• 弹性
• 韧性
• 零信任

无服务架构（Serverless） #

如果说微服务架构是分布式系统这条路的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。

AI原生 + 云原生 #

AI 应用目前还在探索阶段，各种概念层出不穷。最开始的提示词工程、上下文工程、spec，到现在的 skills，都是为了做一件事：表达和显化私域经验，封装部分逻辑来简化做某些事情的过程。
我相信这些都是探索过程中的中间产物，最终还是会泾渭分明：AI 大模型与人的连接这个部分，会逐渐细分成多个领域横向发展。

从软件的历史看架构的未来 #

第一次软件危机 1950 年代末期 #

机器强大到世界上最聪明的人都无法为它编写出合适的程序了。

• 面条式代码转向结构化编程（1970 年）
• 世界上最聪明的科学家 / 工程学家在开发软件

第二次软件危机 1970 年（北约 NATO 会议） #

每个人都有自己的理解与认知，如何让各个模块能准确地协同工作成了一场灾难。

• 面向对象编程逐步取代了面向过程的结构化编程
• 1990 年代面向对象的设计方法成为主流
• 社会中的高智商高学历精英群体在开发软件

第三次软件危机 2010 年左右开始兴起 #

只要软件系统由大量人员共同研发，并使其分布在云中大量节点协同运行，随着项目规模增大、时间变长，就肯定会有人疏忽犯错，会有代码携带缺陷，会有电脑宕机崩溃，会有网络堵塞中断，总之，必然会受到墨菲定律的无情打击。

从单体到微服务的最根本推动力，是为了方便某个服务能够顺利地“消亡”与“重生”。

如何采用不可靠的部件来构造出一个可靠的系统，是软件架构适配云与分布式算力发展的关键所在。

允许更平庸的开发者也能写出可运行、可用于生产的软件产品，同时又对精英开发者提出更多、更复杂的技术要求。

软件发展的下一个关键矛盾 #

算力规模超过人应掌握合理知识的极限。

• 云原生
• 微服务
• 不可变基础设施
• 弹性计算
• 服务网格
• 无服务器架构
• 高低零代码

设法把那些重要但普适的知识标准化并下沉。

把复杂的问题尽量关进笼子，由专业人员去看护，才能让普通程序员更好参与软件开发，甚至通过低 / 零代码工具的支持，让那些没有太多编程知识、却有丰富领域知识的业务专家，也能够独立制造出优秀的软件产品。