azure 最佳实践-- 为演化而设计

为演化而设计

为演化而设计是持续创新的关键。

所有成功的应用程序都在随时间的推移而演变，无论是错误修复，添加新功能，引入新技术，还是提高现有系统的可扩展性和弹性。如果应用程序的所有部分都紧密耦合，则导致系统将很难更改。应用程序的一部分更改可能会影响另一部分，或导致整个代码库大幅度改动。


这个问题并不局限于单一应用程序。应用程序可以分解为服务，但仍存在使系统刚性和脆弱的紧耦合。但是当服务而演化而设计时，团队就可以持续创新并提供新功能。
微服务正在成为为演化而设计的一种流行方式，因为它们解决了这里所列举的许多因素。


建议做法
强调高内聚和松耦合。如果服务提供了逻辑上属于一体的功能，那么服务就是高内聚的。如果可以更改一个服务而不影响其他服务，则服务是松耦合的。高内聚一般意味着一项功能的改变将需要（同一服务的）其他相关功能的改变。如果发现更新服务时需要对其他服务进行更新，那么这可能表示服务的内聚性不够高。域驱动设计（DDD）的目标之一就是识别这些边界。


封装领域知识。当客户端调用服务时，执行领域内业务逻辑的责任不应归为客户端。相反，该服务应该包含所有属于其责任的领域知识。否则，每个客户端都必须执行相同的业务逻辑，并且要在应用的不同部分扩散这些知识。


不要在网关中放业务逻辑。网关在微服务架构中可能会有用，例如请求路由，协议转换，负载平衡或认证等。但是，网关应该仅限于这些基础架构功能。它不应该了解任何领域的业务，以避免带来强依赖。


暴露接口。避免创建位于服务定义逻辑层。相反，服务间应开放具有协议明确的API。应该对API进行版本控制，以便可以在保持向后兼容性的同时对API进行演变。这样就可以更新服务的同时不必对依赖于它的上游服务进行协调更新。面向公众的服务应通过HTTP暴露RESTful API。出于性能考虑，后端服务间通信可能会使用RPC风格的消息传递协议。


设计并测试服务间的协议。当服务公开明确的API时，就可以开发并测试这些API。这样，就可以单独的对服务进行开发并测试，而不再需要解除对所依赖服务的耦合。（当然，也会执行集成和负载测试）


将基础架构从业务逻辑中抽象出来。不要让业务逻辑与基础架构相关功能（如消息传递或持久性）混在一起。否则，业务逻辑中的更改将可能需要更新基础结构层，反之亦然。


将cross-cutting（横切方面）放在各自的服务中。例如，如果多个服务需要对请求进行身份验证，则可以将此功能移到其自己的服务中。然后，可以对身份验证逻辑进行演变，例如，添加新的身份验证流程，而不会影响到使用它的服务。


隔离部署服务。当DevOps团队可以对应用程序中的某个服务进行单独部署时，可以更快速，安全地进行服务更新。错误修复和新功能的进行也会更流畅。对应用程序和发布过程设计，以支持独立更新。