微服务架构

宏观问题的微观解决方法？

微服务的炒作无处不在，尽管业界似乎无法就确切的定义达成共识，但我们一再被告知，从单一应用程序转向由小型服务组成的面向服务的体系结构(SOA)是正确的方法。构建和发展软件系统。 但是，目前没有传统的“企业”组织谈论采用微服务。 这篇博客文章是对较大文章的预览，该文章探讨了企业中微服务的使用。

界面–良好的合同造就了好邻居

无论您是开始新建的微服务项目，还是要负责将现有的整体解构为服务的任务，首要任务都是定义新组件的边界和相应的应用程序编程接口(API)。

与使用传统的面向企业服务的体系结构(SOA)方法通常实现的服务相比，微服务体系结构中建议的服务粒度要更好，但是可以说SOA的初衷是创建可重用业务功能的内聚单元，甚至如果实施历史讲述了一个不同的故事。

新建的微服务项目通常具有更大的灵活性，并且初始设计阶段可以使用服务提供者与消费者之间的明确责任和合同(例如，使用消费者驱动合同)来定义域驱动设计(DDD )启发的有限上下文。

但是，典型的棕地项目必须寻求在现有应用程序中创建“接缝”，并实现与接缝接口集成的新(或提取)服务。 目标是使每个服务具有高凝聚力和松散耦合； 服务接口的设计是这些原则的种子。

通信–同步与异步

实际上，我们发现许多企业将需要在其服务中同时提供同步和异步通信。 值得注意的是，尽管这些框架所解决的许多挑战仍然存在，但行业内仍在推动人们摆脱人们认为的“重量级” WS- *通信标准(例如WSDL，SOAP，UDDI)。服务发现，服务描述和合同协商(如greg Young在muCon微服务会议上的最新演讲中非常简洁地阐述)。

中间件–传统企业如何应对？

尽管许多重量级的Enterprise Service Bus ESB可以执行一些非常巧妙的路由，但它们经常被部署为黑匣子。 吉姆·韦伯(Jim Webber)曾开玩笑说ESB应该代表“ Egregious Spaghetti Box”，因为在专有ESB中执行的操作并不透明，而且通常很复杂。

如果要求指示使用ESB(例如，消息拆分或基于策略的路由)，那么您考虑的第一个选项就是开源轻量级ESB实现，例如Mule ESB或Fuse ESB 。

我通常发现轻量级的MQ平台(例如RabbitMQ或ActiveMQ )更适合，因为我们认为SOA通信的当前趋势是朝着“哑管道和智能端点”迈进，除了消除潜在的供应商费用和锁定外，其他好处使用轻量级的MQ技术可以简化部署，管理和简化测试。

部署微服务–有多难？

无论您选择构建微服务，使用连续集成样式的构建管道都是至关重要的，该管道包括针对功能需求，容错，安全性和性能的严格自动化测试。 在“速度取胜”且快速创新和试验的能力是竞争优势的经济中，手动QA和分阶段评估的经典SOA方法可能不再合适(正如精益创业运动所体现的那样)。

您的应用程序的行为可能会在基于微服务的平台中浮现出来，尽管没有什么可以替代对您的生产堆栈中进行全面而广泛的监视，但是在您的组件暴露给客户之前先进行锻炼(或折磨)的构建管道似乎是高度有益。 正如我在几个会议演示中所讨论的那样，一个好的构建管道应尽可能早地在目标部署环境中行使服务。

摘要– API，轻量级的comms和正确的部署

不管您是否订阅了微服务炒作，这种架构风格似乎在所有软件开发领域中都越来越受欢迎。 本文试图为理解这个不断发展的空间中的关键概念提供入门知识，并希望提醒读者，经典企业SOA之前已经见过许多这样的问题和解决方案。 我们明智的做法是不要重新发明众所周知的“面向服务”的方向盘。

请单击此处，以获取完整的原始文章，该文章提供了有关JVM平台上微服务实现选项的更多信息，并讨论了持续交付的要求。 本文的一个版本最初发布在DZone 2014 Enterprise Integration Guide中。

参考文献

完整的参考文献列表和推荐的阅读材料也可以在原始文章和最近讨论微服务业务含义的文章中找到。

翻译自: https://www.javacodegeeks.com/2015/01/microservices-in-the-enterprise-friend-or-foe.html

微服务架构