本文将介绍一些微服务的优秀实践，并提出帮助开发人员设计、编排和保护微服务架构的一些方法。通过了解这些实践，将为开发人员成功开发项目提供帮助。
微服务的好处和挑战
在深入研究微服务优秀实践之前，应该首先了解微服务的好处和挑战，以及为什么要使用它们的原因。
简而言之，微服务是一种改进的软件架构，可以让开发人员：
更快地部署和扩展。更小的应用程序域允许自动化，从而实现更快的部署和更快的扩展。
减少停机时间。限制不可用服务对主要业务功能的影响，从而提高其整体业务的正常运行时间。
确保可用性。使微服务之间的功能保持离散，从而限制实例宕机时的影响。
当然采用微服务拥有这些好处，也会面临着一系列新的挑战，其中包括服务间通信、安全性和可扩展性。
服务间通信。对于单体应用来说，所有模块都可以固有地相互通信。因此需要管理一个证书，一旦请求经过身份验证和授权，就可以毫无问题地遍历代码路径。当开发人员从单体架构中提取一个功能到微服务应用程序时，曾经的内部函数调用变成了需要对这个外部微服务进行身份验证和授权的外部API调用。
安全层。认证和授权在单体应用中，可以在入口处一次性处理。随着向微服务的过渡，每个微服务都需要执行一些身份验证和授权以强制执行访问控制。但是要求用户每次使用不同的微服务都要进行登录是不现实的，因此需要建立一个全面的认证策略。
可扩展性。尽管微服务允许开发人员快速扩展独立功能，但要有效地做到这一点，需要良好的应用程序管理甚至更好的工具。可扩展性的有效性取决于开发人员的微服务编排平台，以下将更详细地进行讨论。
微服务的优秀实践
在对微服务的好处和挑战的快速概述之后，以下深入研究微服务的一些优秀实践。这些优秀实践将帮助开发人员创建一个强大、易于管理、可扩展且安全的互通微服务系统。
1.较小的应用程序域
采用微服务策略需要遵循单一职责原则。通过限制单一服务的责任范围，可以降低该服务失败的负面影响。如果单个微服务的责任太多，发生故障或不可用将对系统的其余部分产生多米诺骨牌效应。
顾名思义，微服务是微小的服务，而保持微服务的应用程序域很小，可以专用于一项逻辑功能。如果出现任何问题，这将减少特定的微服务的影响。此外，较小的服务更易于维护，其结果是更容易更新和更快的开发。
那么这在实践中是什么样子的?例如，假设微服务是一个API服务器，它接受获取数据的请求，并且这些请求必须附带一个授权令牌。在刚开始时，这是唯一需要授权令牌的微服务。为什么不将身份验证和令牌生成作为微服务的一部分?乍一看，其优点是活动部件少，管理工作少。
当然，开发人员如果拥有需要授权令牌的其他服务，则很快就会发现原来的微服务将充当API服务器和身份验证服务器。如果API服务器宕机，那么其身份验证服务器也会随之宕机。这样，所有其他需要授权令牌的服务也是如此。
因此考虑未来的发展，开发人员需要保持微服务的微小化。
2.数据存储分离
连接到同一个数据库的多个微服务本质上仍然是一个单体架构。单体应用只是运行在数据库层而不是应用层，这使得它同样脆弱。每个微服务都应该尽可能地拥有自己的数据持久层。这不仅确保了与其他微服务的隔离，而且如果特定数据集变得不可用，还可以最大限度地减少影响范围。
有时，不同的微服务访问同一数据库中的数据似乎是有意义的。然而，更深入的研究可能会发现，一个微服务仅适用于数据库表的子集，而另一个微服务仅适用于完全不同的数据库表子集。如果这两个数据子集是完全正交的，那么这将是将数据库分离为单独服务的一个很好的例子。这样，一个服务依赖于其专用数据存储，并且该数据存储的故障不会影响除该服务之外的任何服务。
以文件存储为例。在采用微服务架构时，不需要单独的微服务使用相同的文件存储服务。除非有实际的文件重叠，否则单独的微服务应该有单独的文件存储。
这种数据分离提高了灵活性。例如，假设有两个微服务都与云计算提供商共享相同的文件存储服务。其中一个微服务经常接触大量文件，但这些文件很小，而另一个微服务只有几个定期访问的文件，但这些文件的大小很大，达到数百GB。
对这两个微服务使用通用的文件存储服务将会降低优化成本的灵活性，这是因为同时拥有大文件和小文件以及定期访问的混合。如果每个微服务都有自己的数据持久层(当然可以是一个单独的微服务)，那么就可以更灵活地找到更适合该单个微服务需求的提供者或服务。
成本优化、选项的灵活性以及对可能失败的单一解决方案的更少依赖，这些都是分离不同微服务数据的原因。
3.沟通渠道
微服务之间如何沟通需要深思熟虑，特别是在
