7、微服务应用架构解析

微服务应用架构解析

1. 整体架构概述

作为软件设计师，我们期望构建易于变更的软件。软件面临着诸多压力，如新需求、缺陷、市场需求、新客户以及业务增长等。理想情况下，我们应能从容应对这些压力。为实现这一目标，开发方法需减少摩擦并降低风险。

工程组织希望随着系统的发展，消除开发过程中的所有障碍。我们要能够快速无缝地替换任何过时的系统组件，组建能够完全自主负责大型系统部分功能的团队，且这些团队无需持续同步工作，也不会相互阻碍。这就需要我们精心规划应用架构。

1.1 从单体应用到微服务

单体应用的主要交付物是一个单一的应用程序，它通常水平划分为不同的技术层（如典型的三层应用中的数据层、逻辑层和表示层），垂直划分为不同的业务领域。MVC 模式以及 Rails 和 Django 等框架都体现了三层模型。每层为上一层提供服务：数据层提供持久状态，逻辑层执行具体工作，而表示层将结果呈现给最终用户。

单个微服务与单体应用类似，它存储数据、执行一些业务逻辑，并通过 API 将数据和结果返回给消费者。每个微服务拥有应用的一项业务或技术能力，并与其他微服务交互以完成工作。

单体应用的架构局限于应用本身的边界，而微服务应用则需要规划一个在规模和广度上不断发展的系统。可以将构建单体应用比作建造一座摩天大楼，而构建微服务应用则如同建设一个社区，需要建设基础设施（如管道、道路、电缆）并规划发展（如划分小企业区和住宅区）。

这个类比强调了不仅要考虑组件本身，还要考虑它们的连接方式、放置位置以及如何并行构建它们的重要性。我们的规划应鼓励良好的发展，而不是强行规定整体应用的结构。

以下是典型三层单体应用架构和单个微