微服务架构原则

        围绕DDD的领域概念定义，并将技术架构和所依赖的其他组件封装到限界上下文中，构建了高度解耦的架构。每个服务包含其限界上下文的所有部分，并通过消息（例如REST或消息队列） 和其他限界上下文进行通信。因此，服务不需要知道另一个服务的实现细节（例如数据库模式），从而避免了不当的耦合。该架构的运作目标是用一个服务取待另一个服务而不影响其他服务。

微服务架构通常遵循以下七个原则：

1、围绕业务领域建模

微服务设计的重点是基于业务领域，而不是基于技术架构。因此，架构量子反映了限界上下文。一些开发人员错误地认为限界上下文代表某个单独的实体，例如客户。相反，它代表某个业务上下文或工作流，例如商品结账。微服务的目标是创建有用的限界上下文，而不是让开发人员构建更小的服务。

2、隐藏实现细节

        微服务的技术架构封装在基于业务领域的服务边界中。每个领域形成一个物理限界上下文。服务间通过传递消息或资源来集成，而不是通过暴露实现细节集成。例如数据库模式。

3、自动化文化

        微服务架构支持持续交付，它使用部署流水线严格的测试代码，并将一些任务自动化，例如服务器准备和部署。在高速变化的环境中，自动化测试能发挥巨大作用。

4、高度去中心化

        微服务形成了一种无共享架构，其目标是尽可能地减少耦合。通常重复好于耦合。例如商品结账和送货服务都包含项的概念。由于在两个服务中，这个概念的名称和属性相同，因此，为了节省时间和工作量，因为变更会影响所有公用该组件的团队。不仅如此，在变更某个服务时，开发人员还要担心对共享组件的修改，相反，如果每个服务有其自己的项，并将其所需的信息从商品结账传递到送货服务，而不需要耦合组件，那么他们便可以各自进行变更。

5、独立部署

        开发人员和运维人员希望可以独立部署每个服务（包括基础设施），反映了服务间的物理限界上下文。微服务架构的一个明显的优点是开发人员可以在不影响其他服务的情况下部署某个服务。而且，开发人员通常会自动化所有的部署和运维服务，例如并行的测试和持续交付。

6、隔离失败

        开发人员会在微服务上下文中和服务间的协调中隔离失败。每个服务都应该处理合理的错误场景并在可能的情况下将其恢复。很多DevOps的最佳实践通常在这种架构中出现，例如熔断器模式、舱壁模式等。很多微服务架构遵循这响应式宣言，它是一系列运作和协调原则，遵循这些原则可以构建出更加强大的系统。

7、高度可观察

        开发人员不能期望人工监控成百上千个服务（一个开发人员无法观察多个SSH终端会话）。因此，在微服务架构中监控和日志成了首要问题。如果运维人员无法监控某个服务，那么它相当于不存在。