微服务架构的正常运行离不开一组精心构建的独立组件，它们可以高效协同工作。模块化组件之间的相互依赖性构建了更大的应用程序本体。但是在实际开发中，当微服务被分解成最基本的单元时，要保证微服务以最基本的方式工作并不容易。否则，应用程序的整体效用就无法实现。不要因为设计错误而拒绝微服务架构，牢记以下五个黄金设计原则，你的微服务架构将拥有强大的组件支持。第一，聚焦一个问题。迈向微服务的第一步是为服务设置一个独特的问题。例如，假设一家汽车贸易组织想要构建一个应用程序，将潜在买家与卖家联系起来。基于此，将有一个专门的微服务组件来处理汽车的购买、销售或转售，而没有任何服务的其他用途。支付链接是设计中的另一个关键组成部分。虽然这两个微服务可以相互组合和使用，但服务并不融合。每个元素负责不同的任务，并且始终独立工作。其次，它具有离散属性。微服务执行其工作所需的所有逻辑和数据都驻留在自身内部，并且与其他微服务组件完全隔离。虽然微服务往往需要自己配置才能让内部组件正常运行，但这种配置不会影响其他微服务的配置。只有坚定地坚持这一设计原则，开发者才能根据实际负载需求随时扩展各种服务。第三，拥有自己的数据。微服务不应该只承载自己的数据，这些数据也应该独立于其他微服务组件。在某些情况下，微服务甚至可能拥有自己的数据库。在其他情况下，微服务可能与其他服务共享同一个数据库，但在该数据库中仍然有自己唯一的数据库表。一般来说，开发者会使用共享数据库来降低成本，但这显然违背了微服务架构的设计原则。开发人员通常需要在设计中同时考虑数据独立性和冗余性。每个微服务自身数据的设计可能会造成应用层面的数据重复，但开发者开始接受微服务设计模式必然导致数据冗余的基本事实。要理解不同微服务之间的数据重复问题，最直观的例子就是存储在不同电商平台的客户数据。具体来说，同一个用户很可能分别注册了亚马逊和沃尔玛，所以这两个网站都有一组关于该用户的数据。但由于这两个站点保持独立且隔离良好，除非它们具有明确的数据访问授权，否则两者都知道用户的数据也存在于另一个站点上。第四，可转让。所谓微服务的可迁移性，就是我们可以将它们“打包”成部署单元，比如容器镜像或者serverless函数，随时通过CI/CD流程部署到给定的目标上。例如，开发人员可以轻松地将可传递的微服务部署到GoogleCloud等云提供商。如果需要部署到其他云平台，开发人员可以随时将相同的微服务传递给AWS。第五，它是暂时的。微服务的短暂性意味着我们可以随时销毁它们并立即将服务恢复到最后已知的状态。容器的临时性不仅决定了当前容器下线后应用状态的管理方式，还影响了管理思想甚至是活动线程的具体设计，以保证代码不存在基于线程的依赖.这五个黄金原则应该成为所有微服务架构的核心设计要求。仔细考虑每个原则，为您当前的应用程序创建一个好的架构。
