架构01-演进中的架构

零、文章目录

架构01-演进中的架构

1、原始分布式时代：Unix设计哲学下的服务探索

（1）背景

• 时间：20世纪70年代末到80年代初
• 计算机硬件：16位寻址能力、不足5MHz时钟频率的处理器、128KB左右的内存
• 转型：从大型机到微型机，计算机逐渐从科研设备转变为商业和家用设备

（2）探索动机

• 硬件限制：单台计算机的运算处理能力有限，阻碍了信息系统软件的最大规模
• 目标：使用多台计算机共同协作，支撑同一套软件系统的运行

（3）重要技术和概念

• Network Computing Architecture (NCA)：远程服务调用的雏形
• Andrew File System (AFS)：分布式文件系统的最早实现
• Kerberos 协议：服务认证和访问控制的基础性协议
• **Distributed Computing Environment (DCE)：**一套完整的分布式服务组件规范与实现
  • 远程服务调用规范 (RPC)
  • 分布式文件系统 (DFS)
  • 服务认证规范
  • 时间服务、命名与目录服务
  • 通用唯一识别符 (UUID)

（4）DCE 的特点

• 透明化：尽可能透明化分布式环境中的服务调用、资源访问、数据存储等操作
• 复杂性：远程方法调用与本地方法调用的复杂度差异巨大，涉及服务发现、负载均衡、网络分区、超时、错误处理、序列化协议、传输协议、服务权限管理、通信安全、分布式数据一致性等问题

（5）面临的挑战

• 性能与分布式设计的矛盾：开发者需在方法运行时间和远程调用成本之间做出权衡
• 编程技巧要求高：设计良好分布式应用需要极高的编程技巧和知识

（6）结果与教训

• DCE 和 CORBA 的局限性：分布式带来的问题和代价超过了其收益
• 凯尔·布朗的评价：某个功能能够进行分布式并不意味着应该进行分布式，强行追求透明的分布式操作只会自寻苦果

（7）后续发展

• 单体时代的兴起：摩尔定律作用下，单机处理能力迅速提升，单体系统成为主流
• 分布式计算的持续探索：对远程服务调用的探索从未中断，现代 RPC 和 RESTful 成为关键

2、单体系统时代：应用最广泛的架构风格

（1）单体架构的定义与历史

• 定义：单体架构是一种将所有组件结合成一个单一程序的软件架构风格。
• 历史：
  • 出现时间最早、应用范围最广、使用人数最多、统治历史最长的架构风格。
  • "单体"这一概念是在微服务流行后才被"事后追认"的。
  • 缺乏专门的开发材料，体现了其简单性和普遍性。

（2）单体架构的优势

• 易于开发：开发工具（如IntelliJ IDEA、Eclipse）对单体架构友好，提供强大的代码分析、重构、部署和调试能力。
• 易于测试：所有功能、模块、方法的调用在进程内进行，测试更为简便。
• 易于部署：单体系统可以轻松部署和管理。
• 高效交互：进程内调用无需进程间通信，运行效率高。
• 适用于小型系统：对于小型系统，单体架构不仅易于开发、测试、部署，而且运行效率高。

（3）单体架构的误区

• **并非不可拆分：**单体系统可以在纵向和横向上进行拆分。

  • 纵向拆分：采用分层架构，实现不同层次的拆分和数据流转传递。

  

  • 横向拆分：支持按技术、功能、职责等角度进行模块化拆分，以便重用和团队管理。

• 并非一定会被微服务取代：单体架构在某些场景下仍然具有优势，不应被简单地贴上"落后"的标签。

（4）单体架构的缺陷

• 隔离与自治能力欠缺：
  • 全局影响：任何部分的代码出现问题，都会影响整个系统的运行。
  • 资源消耗：内存泄漏、线程爆炸等问题会影响整个程序甚至整台机器。
• 动态可维护性差：
  • 停机更新：无法单独停止、更新某一部分代码，需要制定专门的停机更新计划。
  • 灰度发布复杂：相比微服务，灰度发布更加复杂。
• 技术异构困难：
  • 技术栈限制：虽然可以通过JNI等技术实现异构，但非常麻烦。

（5）单体系统与微服务的对比

• 微服务的优势：
  • 隔离与自治：每个服务独立运行，互不影响。
  • 动态可维护性：可以单独更新、部署服务。
  • 技术异构：允许使用不同的技术栈。
• 单体系统的适用场景：
  • 小型系统：单体架构在小型系统中表现出色。
  • 性能需求不高：对于不需要高度扩展和隔离的系统，单体架构更为合适。

（6）未来发展方向

• 持续优化：单体系统将继续优化，提高其在大规模系统中的适用性。
• 混合架构：结合单体和微服务的优势，形成混合架构，以适应不同的业务需求。

3、SOA时代：成功理论与失败实践

（1）SOA架构的背景

• 首次广泛使用：SOA架构是第一次被广泛使用的通过分布式服务来构建信息系统的工程实践。
• 技术问题解决：SOA架构解决了分布式系统中几乎所有主要的技术问题。
• 未成为普适架构：尽管有完善的理论和工具，SOA架构最终未能成为一种普适的软件架构。

（2）代表性服务拆分架构模式

• 烟囱式架构：

  • 特点：系统之间完全不互操作或协调。
  • 问题：现实中几乎不存在完全不交互的部门或系统。

  

• 微内核架构：

  • 特点：核心系统集中管理公共数据和资源，业务系统以插件形式存在。
  • 优点：可扩展、灵活、天然隔离。
  • 局限：假设各插件模块之间不直接交互，不适用于需要频繁交互的场景。

  

• 事件驱动架构：

  • 特点：通过事件队列管道实现子系统间的通讯。
  • 优点：独立、高度解耦，可以顺畅地互相调用通讯。

  

（3）SOA架构的发展历程

• 提出：Gartner公司在1994年提出SOA概念。
• 标准化：
  • OSOA联盟：2006年成立，联合制定和推进SOA相关行业标准。
  • OASIS：2007年，OSOA转变为制定行业标准的国际组织。
  • Open CSA：联合OASIS成立，负责SOA的管理。

（4）SOA架构的特点

• 更具体：
  • 技术标准：拥有领导制定技术标准的组织。
  • 设计原则：服务的封装性、自治、松耦合、可重用、可组合、无状态。
  • 协议：采用SOAP协议族进行服务的发布、发现和治理。
  • 企业服务总线（ESB）：实现子系统间的通讯交互。
  • 服务数据对象（SDO）：访问和表示数据。
  • 服务组件架构（SCA）：定义服务封装和服务运行的容器。
• 更系统：
  • 目标：总结出一套自上而下的软件研发方法论，解决软件开发过程中的全套问题。
  • 愿景：实现软件开发的工业化大生产。

（5）SOA架构的失败原因

• 复杂性：
  • 严谨流程：需要专业人员才能驾驭。
  • 过度复杂：Web Service的兴起与衰落，ESB、BPM、SCA、SDO等上层建筑进一步加剧了复杂性。
• 与EJB的相似之处：
  • 失败原因：脱离了人民群众，被"草根框架"打败。

（6）总结与思考

• 成功部分：提出了技术解决方案，解决了分布式环境下的主要技术问题。
• 失败部分：过于复杂的流程和理论限制了其普及。
• 未来展望：微服务时代的开启，带着对SOA架构的自省。

4、微服务时代：SOA的革命者

（1）微服务的起源与发展

• 早期提出：2005年，Peter Rodgers博士在云计算博览会上首次提出"Micro-Web-Service"概念，指的是专注于单一职责、与语言无关的细粒度Web服务。
• SOA背景：微服务最初是作为SOA的一种轻量级补救方案提出的，被视为SOA的一个变种。
• 发展过程：在最初的10年里，微服务并未受到广泛关注。2012年，Thoughtworks首席咨询师James Lewis在"33rd Degree Conference"大会上提出了微服务的现代定义，强调了单一服务职责、康威定律、自动扩展、领域驱动设计等原则。

（2）现代微服务的定义与特征

• 定义：微服务是一种通过多个小型服务组合构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。
• 核心特征：
  1. 围绕业务能力构建：强调康威定律的重要性，团队结构应与产品结构一致。
  2. 分散治理：开发团队对服务运行质量负责，有权选择技术实现。
  3. 独立自治的组件：通过服务而非类库实现组件化。
  4. 产品化思维：软件研发应视为持续改进的过程，开发团队负责整个生命周期。
  5. 数据去中心化：数据按领域分散管理。
  6. 轻量级通讯机制：反对复杂的通讯机制，提倡简单的RESTful风格。
  7. 容错性设计：接受服务会出错的现实，设计自动故障检测和隔离机制。
  8. 演进式设计：服务应能被报废淘汰，系统不应存在不可更改的服务。
  9. 基础设施自动化：CI/CD等自动化工具降低运维复杂性。

（3）微服务与SOA的区别

• 拒绝SOA标签：微服务支持者倾向于拒绝SOA标签，尽管有些人认为微服务是SOA的一种变体。
• 自由与约束：微服务追求更自由的架构风格，摒弃了SOA的复杂技术标准，但这也带来了新的挑战，如服务间通讯和服务发现等问题。

（4）微服务的优势与挑战

• 优势：
  • 降低复杂度：简单服务不必同时面临所有分布式问题。
  • 灵活选择：根据需要引入工具，团队熟悉的技术优先。
  • 友好开发：Spring Cloud等工具集降低切换成本。
• 挑战：
  • 高要求架构者：对架构能力的要求极高，需要权衡利弊。
  • 选择困难：多种解决方案并存，缺乏统一标准。

（5）未来展望

• 自由与迷茫：微服务时代充满自由，但也伴随着选择的迷茫。
• 持续探索：微服务可能不是架构探索的终点，未来的信息系统需要同时拥有自由权利和解决分布式问题的能力。

5、后微服务时代：跨越软件与硬件之间的界限

（1）引言

• 背景：微服务架构面临的问题（注册发现、跟踪治理、负载均衡、传输通讯等）在分布式系统中普遍存在。
• 问题：这些问题是否必须由分布式系统自己解决？

（2）常见的解决方法

• 伸缩扩容：购买新的服务器，多部署几套副本实例。
• 负载均衡：布置负载均衡器，选择合适的均衡算法。
• 安全传输：布置 TLS 传输链路，配置 CA 证书。
• 服务发现：设置 DNS 服务器，使用稳定的服务名。

（3）微服务时代的无奈

• 原因：硬件基础设施的灵活性无法跟上软件应用服务的灵活性。
• 解决方案：虚拟化技术和容器化技术（如 Docker）的兴起。

（4）容器生态的发展

• 里程碑：2017 年 Kubernetes 赢得容器战争的胜利。
• 事件：
  • CoreOS 放弃 Fleet，转向 Kubernetes。
  • Rancher Labs 提出"All-in-Kubernetes"战略。
  • Apache Mesos 宣布"Kubernetes on Mesos"集成计划。
  • Docker 宣布支持 Swarm 与 Kubernetes 两套容器管理系统。

（5）Kubernetes 的贡献

• 虚拟化基础设施：容器间网络、服务、负载均衡、配置等。
• 目标：开启下一个软件架构发展的新纪元。

（6）云原生时代的到来

• 定义：通过一系列小型服务构建大型系统。
• 特点：软件与硬件的界限模糊，应用代码与基础设施软硬一体。
• 前景：实现"透明的分布式应用"、"凤凰服务器"、"不可变基础设施"。

（7）Kubernetes 的局限

• 问题：某些边缘问题难以在基础设施层面精细化解决（如熔断、监控、认证、授权、负载均衡）。

• 解决方案：引入"服务网格"（Service Mesh）的"边车代理模式"（Sidecar Proxy）。

（8）服务网格

• 定义：在服务的资源容器中注入一个通讯代理服务器，实现流量劫持和精细管理。
• 功能：熔断、认证、度量、监控、负载均衡等。
• 优势：无需改动应用代码，提供精细管理能力。

（9）未来展望

• 趋势：Kubernetes 成为服务器端标准运行环境，服务网格成为微服务间通讯交互的主流模式。
• 目标：业务与技术完全分离，远程与本地完全透明。

6、无服务时代："不分布式"云端系统的起点

（1）分布式架构的背景

• 初衷：解决单台机器性能瓶颈
• 演进：考虑容错能力、技术异构、职责划分等
• 现状：虽然分布式架构带来性能提升，但也引入了新的问题（如服务安全、容错、分布式事务一致性）

（2）云计算的崛起

• 无限性能：云计算提供了相对无限的性能支持
• 云服务提供商：AWS、阿里云等能够满足系统对性能的需求

（3）无服务架构的兴起

• 概念提出：2012年，iron.io公司率先提出
• 商业化应用：2014年，AWS发布Lambda
• 国内发展：2019年，阿里云、腾讯云等发布无服务产品

（4）无服务架构的核心

• 后端设施：数据库、消息队列、日志、存储等，统称为"后端即服务"（BaaS）
• 函数：业务逻辑代码，统称为"函数即服务"（FaaS）

（5）无服务架构的优势

• 简化开发：开发者只需关注业务逻辑
• 无需考虑技术组件：现成的后端设施
• 无需考虑部署：部署过程完全托管到云端
• 无需考虑算力：算力被认为是无限的
• 无需操心运维：云服务商负责系统平稳运行

（6）无服务架构的局限性

• 冷启动：函数在请求到达时才开始运行，导致延迟
• 无状态：不适合依赖服务端状态的应用
• 运行时间限制：函数运行时间受限
• 适用场景：适合离线大规模计算、Web资讯类网站、小程序、公共API服务、移动应用服务端等

（7）无服务架构的未来

• 谨慎乐观：类似于微服务架构的早期，无服务架构的推广仍需时间
• 融合互补：未来多种架构风格将共存，分布式与非分布式边界将模糊
• 应用案例：企业微信、QQ小程序、腾讯新闻等产品已使用无服务框架