微服务设计原则
每个架构都是基于某些设计原则而形成的，微服务也是。 本文中将讨论构建基于微服务的架构所需要的一些设计原则。
隔离
服务必须设计为单独相互隔离工作。 当你将一个整体单片系统分解成一组服务时，这些服务必须彼此解耦，这样才能更加连贯和自给自足。每个服务应该能够处理其自己的故障，而不会影响或破坏整个应用程序或系统。 隔离和解耦特性使服务能够非常快速地从故障状态中恢复。服务的隔离特性具有以下优点：容易采用连续交付，更好的扩展，有效的监控和可测试性。
自治性
隔离为自治性铺平了道路。 服务必须设计为自主自治的。 它必须具有凝聚力，能够独立地实现其职能。 每个服务可以使用良好定义的API（URI）独立调用。 API以某种方式标识服务功能。 自主服务还必须处理自己的数据。 更流行的术语是多语言持久性，其中每个服务都有自己的持久存储。 自主还确保弹性。 自主服务具有以下优点：有效的服务编排和协调，更好的扩展，通过良好定义的API进行通信，更快速和可控的部署。
单一责任
服务必须设计为高度凝聚。 单一的职责（责任）原则是服务只执行一个重要的功能。 单一责任与“微观”一词很好地结合。 ‘微’意味着小，细粒度，只与其责任范围内相关。 单一责任功能具有以下优点：服务组合无缝，更好的扩展，可重用性，可扩展性和可维护性。
有界上下文
您的服务应该有多大或小？ 答案就在于所谓有界上下文设计原则。这是一个关键模式，同时是领域驱动设计（DDD）建模方法。 有界的上下文是关于微服务将提供其服务功能的上下文。它根据有关领域模型和识别离散边界，并相应地设计您的微服务，使其更具凝聚力和自主性。 这也意味着跨边界的通信变得更有效率，在一个有界上下文中的服务不需要依赖于另外一个有限上下文中的太多的事情了。
异步通信
在设计离散边界和使用其自己的有界上下文设计服务时，跨边界的服务通信必须是异步的。异步通信模式自然导致服务之间的松耦合，并允许更好的缩放。使用同步通信，会阻止调用并等待响应。 处于阻塞状态的服务不能执行另一个任务，直到接收到响应并释放底层线程为止。它导致网络拥塞，并影响延迟和吞吐量。异步通信还可以带来实现良好定义的集成或通信模式的概念，以实现涉及不同服务的逻辑工作流。
位置独立
根据设计，微服务是在虚拟化环境或docker容器中部署。随着云计算的出现，我们可以拥有大量可以利用动态缩放环境的服务实例。 服务可以在跨小型或大型集群的多个节点上运行。服务本身可以根据底层计算资源的可用性或效率来重新定位。 必须能够以位置独立的方式来寻址或定位服务。通常，可以使用不同的查找发现模式来消费使用您的服务。服务的客户端或消费者不必烦恼部署或配置特定服务的位置。 它只是使用某种逻辑或虚拟地址来定位服务。
微服务不是一种技术，框架或解决方案。它是一种架构风格，为您提供一种方法来处理单一应用程序的复杂性质。 这种方法是从上述设计原则开始，您可以使用它来构建基于微服务的应用程序。