六种常用的微服务架构设计模式 创建微服务模式的基本最佳实践（下篇）

​​接着上篇文章分享的四个基本最佳实践，《六种常用的微服务架构设计模式 创建微服务模式的基本最佳实践（下篇）》文章来了，小编将为您介绍其余的四个基本最佳实践。

五、监控

对于一个足够复杂的基础设施，可见性是有必要的。微服务从业者很难理解，在他们的软件系统中嵌入一个有效的监控解决方案是至关重要的，而且也很难说这种方案不应该是任何优秀的应用程序的默认状态。理想状态下，无需更改应用程序代码就可以测试软件，但是遵循基本实践（例如，将日志记录为STDOUT/STDERR的事件流）可以更容易在适当的位置建立监控基础设施。当然，这只成功了一半，另外还需要更好地理解这些监控数据。关于如何有效地设计监视器和管理这些监控基础设施的话题在本文中将不进行扩展讨论，但是关于这个话题有许多具体的相关文章，比如James Turnbull的《监控的艺术》。

六、减小批处理

在精益生产中，我们了解到，减少批量方面的重要性。微服务作为一组模式很明显利用了这种方法：使用的服务单元越小，每个服务单元的操作就越简单。当然，您拥有的服务单元越多，与之对应的，其管理就越复杂。

然而，即使不采用微服务模式，您也可以通过更频繁、更少量地进行更改来减少部署单元的大小。即使在将更改部署到一个单体应用中时，实施更小、更频繁的更改所附带的操作规程也是有价值的。

七、容器化

使用容器来构建、隔离和管理部署单元通常是有用的，即使将这应用于单体架构软件，效果也是如此。通过数据表明，使用容器不会带来性能或安全方面的开销，因此推荐使用Docker作为部署的基本单元很容易。更好的一点是，微服务模式通常需要容器化技术，因此采用容器是为使用微服务做好准备的一个良好步骤。

八、关注领域驱动设计

由于其对微服务架构的高适用性，领域驱动设计得到了新的普及。虽然，根据过往经验，在大规模的微服务环境中，过度使用DDD（领域驱动设计）可能会分散注意力，但是领域驱动设计提出的实践方法具有很高的价值，并且在一般情况下，这种实践具有很大的应用价值，这一点是毋庸置疑的。此外，领域驱动设计可能更适合于单体模式的设计，而不是微服务模式，因此，在您的软件中采用领域思维将是有益的，并且如果您需要进行更改时，这种思维将为向微服务的过渡铺平道路。

总结：建立适合您组织的微服务模式

既然您已经阅读了不同的微服务模式，那么评估哪种模式最适合您的组织就很重要了。它可以是一个，也可以是一个集合，或者您可能决定继续使用一个单体架构。

重要的是要记住，微服务并不是解决所有问题的灵丹妙药。它是一种设计用来克服障碍的架构，如果正确部署，将产生特定的预期结果。

在这里讨论的六种常用设计模式将如何演变，以及软件将如何兴起来简化这种高度复杂方法的挑战，这些都还有待观察。然而，很明显，许多企业将转向采用微服务模式，我们希望通过提供这些模式的一些定义，可以帮助这些组织避免许多最明显和痛苦的错误。

关于灵长科技

灵长科技自主开发的智能连接和数据集成平台CEAMS，是为Node.js技术生态中的API和微服务应用开发者量身定做的微服务应用开发，以及API运维管理系统。将系统连接、数据集成、业务逻辑全部通过松耦合集成于一体的开发平台。系统的目标客户主要是系统和数据集成开发者。开发者利用CEAMS系统，可以通过统一的规范模式，快速地与各类IT系统，数据库，云计算服务和智能设备高效对接，平台不仅帮助开发者简化了许多与底层设备对接的复杂操作，并基于提供大量的自动化工具。CEAMS系统已在国内包括省级政务云平台等多个IT项目中得到成功应用，并在单个项目中支持数十位开发者同时在线开发和管理自身的后台微服务应用。目前，CEAMS系统已开放免费下载使用，感兴趣的用户可以点击下方链接

https://www.apemesh.com/cn/do...

了解有关灵长科技产品的更多信息或者与我们联系（email: sales@apemesh.com, 企业QQ技术支持群：618450152）。 目前我们也在招聘Node.js全栈工程师，欢迎有兴趣的朋友们联系小编，向我们了解。

未经同意，本文禁止转载或摘编。​​​​