架构16-向微服务迈进

架构16-向微服务迈进

1、向微服务迈进

（1）软件开发中的“银弹”概念

• **背景：**软件开发过程中常常出现工期延误、预算超支、产品质量低劣等问题，这使得管理者、程序员和用户都渴望找到一种能够显著降低成本的“银弹”。
• **定义：**所谓“银弹”，是指能够一劳永逸解决所有问题的灵丹妙药。
• Fred Brooks 的观点
  • **著作：**Fred Brooks 在其著作《没有银弹：软件工程的本质性与附属性工作》和《人月神话：软件项目管理之道》中反复强调，软件研发中没有任何一项技术、方法或架构能够成为“银弹”。
  • **验证：**这一观点已被软件工程领域的无数事实所验证，适用于包括微服务在内的各种技术。

（2）微服务架构的适用性和局限性

• 适用场景：
  • **复杂系统：**适用于大型、复杂且需要高度可扩展性的系统。
  • **独立团队：**适合多个独立团队并行开发的情况。
  • **高可用性：**需要高可用性和容错能力的系统。
• 不适用场景：
  • **小型项目：**小型项目中引入微服务可能会增加不必要的复杂性和开销。
  • **低耦合需求：**如果系统模块之间的耦合度很低，微服务的优势可能不明显。
  • **技术栈单一：**技术栈单一的项目可能不需要微服务带来的灵活性。

2、目的：微服务的驱动力

（1）目的

• 微服务的主要目的是对系统进行有效的拆分，实现物理层面的隔离，从而实现敏捷开发和部署。
• 通过拆分，局部的单个服务可以独立地进行卸载、部署、开发和升级，使系统整体具备更高的灵活性和可维护性。

（2）驱动力

• 外部因素
  • 技术多样性：
    • 系统可能需要使用多种编程语言和技术栈来实现不同的功能。例如，Java 语言虽然广泛使用，但在某些领域如人工智能和深度学习中，Python 更为适合；在分布式协调工具方面，Etcd 逐渐取代了 ZooKeeper；在缓存方面，Redis 是首选。这种技术多样性的需求使得分布式部署成为必然选择。
  • 人力资源限制：
    • 在某些地区，高质量的开发者资源稀缺，微服务架构可以通过将复杂系统分解为多个小型服务，降低对单一开发者的技术要求，使得普通水平的开发者或外包团队也能参与系统开发，同时由少数技术专家把控关键服务的质量。
  • 商业需求：
    • 客户或甲方的要求可能会推动系统向微服务架构转变。例如，招标文件中明确要求系统支持微服务架构和分布式部署，这种情况下，系统必须满足这些技术规范。
• 内部因素
  • 快速迭代和创新：
    • 对于变化迅速的创新业务系统，微服务架构可以加速功能的上线和迭代。开发、运维和需求团队可以通过微服务实现快速响应市场变化，提高系统的可观测性和自愈能力。
  • 系统复杂性和历史遗留问题：
    • 大规模、业务复杂的系统可能会因历史遗留问题变得难以维护。微服务架构可以通过逐步拆分系统，将不同模块独立出来，实现部分模块的更新和替换，从而延长系统的生命周期。Netflix 就是一个成功案例，通过微服务架构解决了系统复杂性和历史遗留问题。

3、前提：微服务需要的条件

（1）决策者与执行者理解康威定律

• **核心观点：**沟通决定设计（Communication Dictates Design）。
• **组织与产品匹配：**产品和组织最终会自发调整成互相匹配的状态。
• **挑战：**调整组织架构以适应微服务化通常不是一件容易的事，需要良好的社交能力和高层决策者的支持。

（2）组织中具备微服务技术专家

• **技术复杂性：**微服务架构带来了额外的复杂性，需要深刻理解微服务的技术专家来设计和维护。
• **专家角色：**设计健壮的基础设施，持续运维 Kubernetes、Istio、Spring Cloud、Dubbo 等开源工具。
• **人才需求：**技术专家不一定很多，但必须有，尤其是有大型系统经验的专家。

（3）系统具备自动化与监控能力

• 自动化前提：
  • **环境预置：**迅速启动新的服务器。
  • **基础监控：**迅速捕捉系统中的技术问题和业务问题。
  • **快速部署：**通过全自动化的部署管道迅速部署服务变更。
• **自治目标：**构建可持续的生态系统，避免自动化与监控措施成为负担。

（4）复杂性成为主要矛盾

• **单体架构适用性：**对于小型系统，单体架构是最好的架构。
• **生产力曲线：**业务发展到一定程度，单体架构与微服务架构的生产力曲线交叉，此时微服务化才有收益。
• **演进式设计：**系统设计应能够被报废，而非一味追求一步到位。

4、边界：微服务的粒度

（1）微服务粒度的下界

• 微服务粒度的下界是指微服务的最小合理规模。以下是确定下界的关键因素：
  • **独立性：**微服务应能够独立发布、独立部署、独立运行与独立测试。
  • **内聚性：**强相关的功能与数据应在同一个服务中处理，以保证数据的一致性和减少跨服务调用的复杂性。
  • **完备性：**一个服务应包含至少一项业务实体及其完整的操作，避免客户端频繁调用多个服务完成一项业务操作。

（2）微服务粒度的上界

• 微服务粒度的上界是指微服务的最大合理规模。以下是确定上界的关键因素：
  • **团队规模：**康威定律指出，软件架构应与组织架构保持一致。2 Pizza Team（6-12 人）被认为是理想的团队规模，能够有效管理和沟通。
  • **研发周期：**微服务的规模应与团队的研发周期相匹配，确保在一个研发周期内能够完成全部需求。不同研发模式（如瀑布模型、Scrum、精益开发等）会影响上界的大小。

（3）实际应用中的灵活性

• 在确定微服务的具体粒度时，架构师应根据以下几点进行灵活调整：
  • **业务逻辑：**考虑业务操作之间的逻辑关系，合理划分微服务。
  • **团队能力：**评估团队的技术水平和协作能力，选择合适的微服务规模。
  • **研发模式：**根据团队采用的研发模式，调整微服务的粒度以适应不同的迭代周期。

5、治理：理解系统复杂性

（1）概念

• 治理（Governance） 是确保和验证架构中的资产和工件按预期运行并保持一定质量水平的过程。
• 具体来说，治理包括两个层次的要求：
  • **正确执行：**确保软件按预期运行。
  • **持续保持：**确保软件能够持续保持在一定的质量水平上。

（2）微服务架构的复杂性

• 微服务架构虽然强大，但也带来了显著的复杂性。本文从以下几个角度探讨了这种复杂性：
  • 静态治理
    • 认知负荷（Cognitive Load）：
      • 认知负荷是指在软件研发中接受业务、概念、模型、设计、接口、代码等信息所带来的负担。
      • 微服务架构的认知负荷较高，因为分布式系统提倡的理念往往偏向机器而非人，例如异步通信、粗粒度服务接口、容错处理等。
    • 协作成本（Collaboration Cost）：
      • 协作成本是指团队共同研发时付出的沟通、管理成本。
      • 微服务架构通过组织的拆分与产品的拆分对齐（康威定律），将沟通成本从 O(N^2) 降低到 O(NlogN)。
    • 复杂度量化：
      • 微服务架构的复杂度在软件规模小时高于单体系统，但在规模大时低于单体系统。
      • 这是因为微服务的认知负荷较高，但协作成本较低。
  • 动态治理
    • 架构腐化（Architectural Decay）：
      • 架构腐化是指随着时间的推移，软件系统的质量逐渐下降。
      • 原因包括团队成员的变动、代码逐渐失控、技术债务的积累等。
    • 演进式设计：
      • 演进式设计是应对架构腐化的有效方法，类似于生物族群的延续。
      • 它强调在软件发展的过程中不断改进和优化，而不是一次性完成所有设计。

（3）治理的重要性

• **静态治理：**静态治理措施有助于确保软件在初始阶段能够按预期运行，但无法完全避免架构腐化。
• **动态治理：**动态治理通过演进式设计，使软件系统能够在不断变化的需求中保持高质量。