微服务架构的正常运转，离不开一组精心构建、且能够高效协同运作的独立组件。正是模块化组件间的相互依存，构建起规模更大的应用程序本体。
但在实际开发中，在微服务分解成最基础的单元时，确保微服务以最基本的方式运作绝非易事。如果做不到这一点，应用程序的整体效用根本无法实现。不要因为设计错误而拒绝微服务架构，牢记以下五项黄金设计原则，你的微服务架构将拥有强大的组件支持。
第一，专注处理一个问题。迈进微服务的第一步，就是为服务设定唯一的问题。例如，我们假定一家汽车贸易组织希望构建一款应用程序，借此将潜在的买家与卖家联系起来。以此为基础，将有专门的微服务组件处理汽车交易中的买、卖或者转售等操作，任何服务除此之外再无其他用途。
付款环节正是设计中的另一个重点组件。虽然这两项微服务可以相互结合并使用，但这些服务并不会融合起来。每个元素负责处理不同任务，而且始终能够独立起效。
第二，具备离散属性。微服务在执行工作时所需要的全部逻辑及数据都存在于自身内部，而且与其他微服务组件完全隔离。
虽然微服务往往也需要自身配置才能让各内部组件正常运行，但是这种配置不会对其他微服务的配置产生影响。只有牢牢把持这项设计原则，开发人员才能根据实际负载需求随时完成各项服务的规模伸缩。
第三，带有自身数据。微服务不仅应带有自身数据，这些数据还应独立于其他微服务组件之外。在某些情况下，微服务甚至可能拥有自己的数据库。在其他场景中，微服务可能与其他服务共享同一套数据库，但仍在该数据库中拥有自己所对应的唯一数据库表。
通常来讲，开发人员会使用共享数据库以降低成本，但这明显违反了微服务架构的设计原则。
开发人员往往需要在设计中同时考虑到数据的独立性与冗余性。每项微服务自带数据的设计方式可能在应用层级上引发数据重复，但开发者们开始逐渐接受微服务设计模式必然引发数据冗余这一基本事实。
要了解不同微服务之间的数据重复问题，最直观的示例莫过于存储在不同在电子商务平台手中的客户数据。具体来说，同一用户很可能分别注册了Amazon与沃尔玛，因此两个网站都掌握着该用户的一套数据。但由于两个网站保持离散且隔离性极佳，因此除非拥有明确的数据访问授权，否则二者都意识到该用户的数据也存在于另一网站之上。
第四，具备可传递性。所谓微服务的可传递性，代表着我们可以将其“打包”至部署单元，例如容器镜像或者无服务器函数当中，并随时通过CI/CD流程部署到给定的目标中。
举例来说，开发人员可以轻松将可传递微服务部署至Google Cloud这类云服务商。万一需要将其部署至其他云平台，开发者则可随时将同一项微服务传递至AWS。
第五，具备临时性。微服务的临时性，意味着我们可以随时将其销毁，而后立即将服务恢复至最近的已知状态。
容器的临时性质不仅决定了当前容器发生离线后、应用程序状态的管理方式，同时也将影响到活动线程的管理思路甚至是活动线程的具体设计，确保代码不存在基于线程的依赖项。
这五大黄金原则，应当成为一切微服务架构的核心设计要求。请认真考量每项原则，据此建立起适合当前应用程序的良好架构。
