个人做地方网站,杨中市网站建设,网站开发的经验技巧,网站建设推广案例宏观问题的微观解决方法#xff1f; 微服务的炒作无处不在#xff0c;尽管业界似乎无法就确切的定义达成共识#xff0c;但我们一再被告知#xff0c;从单一应用程序转向由小型服务组成的面向服务的架构#xff08;SOA#xff09;是正确的方法。构建和发展软件系统。 但是… 宏观问题的微观解决方法 微服务的炒作无处不在尽管业界似乎无法就确切的定义达成共识但我们一再被告知从单一应用程序转向由小型服务组成的面向服务的架构SOA是正确的方法。构建和发展软件系统。 但是当前没有传统的“企业”组织谈论采用微服务。 这篇博客文章是较大文章的预览该文章探讨了企业中微服务的使用。 界面–良好的合同造就了好邻居 无论您是开始新建的微服务项目还是要负责将现有的整体解构为服务的任务首要任务都是定义新组件的边界和相应的应用程序编程接口API。 与使用传统的面向企业服务的体系结构SOA方法通常实现的服务相比微服务体系结构中服务的建议粒度要更好但是可以说SOA的初衷是创建可重用业务功能的内聚单元甚至如果实施历史讲述了一个不同的故事。 新建微服务项目通常具有更大的灵活性并且初始设计阶段可以使用服务提供者和消费者之间的明确责任和合同例如使用消费者驱动的合同 来定义域驱动设计DDD 启发的有限上下文。 但是典型的棕地项目必须寻求在现有应用程序中创建“ 接缝 ”并实现与接缝接口集成的新或提取服务。 目标是使每个服务具有高凝聚力和松散耦合 服务接口的设计是这些原则的种子。 通信–同步与异步 实际上我们发现许多企业将需要在其服务中同时提供同步和异步通信。 值得注意的是尽管这些框架所解决的许多挑战仍然存在但行业内仍有相当大的动力要摆脱人们认为的“重量级” WS- *通信标准例如WSDLSOAPUDDI。服务发现服务描述和合同协商如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
