第五章 持续交付的软件系统架构

面向服务架构（SOA）

1. 所有的团队都要以服务接口的方式，提供数据和各种功能
2. 团队之间必须通过接口来通信
3. 不允许任何其他形式的互操作，唯一许可的通信方式，就是通过网络调用服务
4. 具体的实现技术不做规定
5. 所有的服务接口，必须从一开始就以可以公开为设计导向，没有例外
6. 如不遵守上述规定，就会被解雇

#“大系统小做”原则

持续交付架构要求

1. 为测试而设计：易于测试新代码
2. 为部署而设计：易于部署新功能
3. 为监控而设计：易于监控新上线的功能
4. 为扩展而设计：支持团队成员规模的扩展，支持系统自身的扩展
5. 为失效而设计：一旦发布或部署失败，如何优雅且快速地处理

系统拆分原则

系统、服务、组件

• 大系统应该由很多组件或服务组成，组件或服务的颗粒度比类大，但比整个系统小很多
• 服务可由多个组件构成，能够独立启动运行，并在运行时与整个系统进行通信
• 组件通常在编译构建或者部署时被集成在一起

系统拆分原则

1. 作为系统的一部分，每个组件或服务有清晰的业务职责，可以被独立修改，甚至被另一种实现方案所替代
2. “高内聚、低耦合”，每个组件或服务只知道尽可能少的信息，完成相对独立的单一功能，使整个系统易于维护
3. 整个系统易于构建与测试。将系统拆分后，组件仍要能够易于组合在一起进行构建和测试
4. 使团队之间的沟通协作更加顺畅