5、软件架构风格全解析

软件架构风格全解析

1. 整体架构的局限性与优势

如果你热衷于在项目中使用前沿技术，整体架构（monolithic style）可能无法带来好消息。因为你需要一次性迁移整个应用程序，更新库或框架变得更加困难。

整体架构仅适用于简单和小型的应用程序。不过，在关注性能时，与微服务相比，整体架构有时能在延迟或吞吐量方面让应用程序发挥出更好的性能。这是因为进程间通信总会产生一些开销，而整体应用程序则无需承担这些开销。

2. 服务与微服务的概念

由于整体架构存在缺点，其他架构方法应运而生。常见的做法是将解决方案拆分为多个相互通信的服务，不同的团队可以分别负责不同的服务，每个团队的工作边界清晰。

面向服务的架构（Service - Oriented Architecture，SOA）将业务功能模块化，并以独立服务的形式提供给消费应用程序使用。每个服务都应有自描述的接口，并隐藏实现细节，如内部架构、技术或使用的编程语言。这使得多个团队可以根据自身需求自由开发服务。例如，一个精通 C# 的团队和一个精通 C++ 的团队可以开发出能够轻松相互通信的两个服务。

SOA 的倡导者提出了一份宣言，优先考虑以下几点：
- 业务价值高于技术战略
- 战略目标高于项目特定利益
- 内在互操作性高于自定义集成
- 共享服务高于特定用途的实现
- 灵活性高于优化
- 渐进式改进高于追求初始完美

常见的服务类型有 SOAP、REST 和近年来越来越受欢迎的基于 gRPC 的服务。

3. 微服务架构

3.1 微服务的定义与特点 <