microservices方法将应用程序分解成更小、模块化的组件,结合业务功能。这允许应用程序的开发工作直接与业务价值优先的功能一致。
Microservices架构可以被认为是专业的迷你应用程序,每一个业务功能服务。他们是封闭和自我控制。所有领域知识所必需的特定任务驻留在microservice和每个microservice都有一个单独的专用数据存储。与其他microservices通信发生在需要的时候,但他们是彼此独立的开发和部署。Microservices架构采用了亚马逊,Netflix, Twitter,乳房和PayPal,等等。 读到Netflix的移动到云上。
Microservices架构并不一定要求软件开发过程,但有助于敏捷方法如Scrum。为持续集成和持续部署(CI / CD),跨职能Scrum开发团队构建microservices自然就很适合。

类比

让我们比较传统的单一应用程序与一个类比microservices建造一个房子的模型。模型的目标是构建一个虚构的五口之家,包括三个卧室,一个浴室,一个厨房和一个客厅。

方法1:单片木头冰棒棍的房子

木棍被小心地粘在一起，直到房子完工。一家人搬进来了，一切都和他们说的一模一样，尽管有人来访时有点拥挤。随着孩子们长大，他们想要自己的卧室。整修期间这家人必须搬走。为了灵活，房间被粘在房子的侧面。这解决了增加一个房间的问题，但进入房间是通过窗户，所以这是不可接受的。同样，家庭必须搬出去，而较长的，但正确的实施，一个房间的增加是架构。孩子们长大后搬进了自己的房子。搬走他们的房间是没有意义的，因为整体式的房子不容易换。

方法2:Microservices魔法乐高房子

每个房间是创建自己的独立的乐高结构、更模块化的方法。房间可以独立移动而不需要拆卸。房子是用神奇的乐高玩具,允许即时的房间和删除重复的房间。当公司来拜访,客厅和卧室可以复制,以适应更高的需求。房间共享不再是一个问题。当需要更少的房间,他们会自动删除。microservices房子更模块化、可伸缩和敏捷比单片的房子。
事情要考虑Microservices提供业务价值
microservices-based方法不是一个银弹,难道一定是明确的选择为您的下一个项目。

Microservices是更适合一些项目与他人。
 

适合

• 应用程序需要可伸缩性。microservices架构的长处之一就是可伸缩性。每个microservice可以独立了。 如果你需要更多的马力为特定的功能,你可以将它添加到只有microservice提供该函数。与今天的云计算技术,可以自动增加或减少计算资源的需求变化。这使得基础设施,支持您的应用程序更容易维护。
• 改变生产需要快速部署。Microservices可以独立开发和部署。 这允许您的开发团队专注于小,高价值功能和部署它们迅速而不用担心关闭应用程序的其他部分。小的功能,microservices很容易测试,因此更加健壮。
• 应用程序功能是高度可配置的。使用软件时客户有不同的需求。是常见的配置在满足他们的需求没有部署独立的应用程序。因为microservices设计和分离功能,很容易切换功能,允许您启用和禁用特定microservice。microservices架构,设计正确,可以毫无顾虑的是高度可配置的影响应用程序的其他部分。
• 软件开发过程支持CI / CD,你的业务有一个SLA和正常运行时间的要求。如果您的业务不使用敏捷方法包括CI / CD,然后你不会利用microservices的全部潜力。这是一个非常强大的功能,可以添加一个小功能或修复一个错误很快就没有麻烦的手动过程将这些更改部署到生产。部署microservice不需要取下未受影响的部分应用程序。如果你的公司是新的DevOps,或者没有DevOps,承担microservices可能为时过早。
   
• 技术战略是与由业务能力和优先级。软件开发优先级并不总是符合业务优先级。有时软件项目是技术驱动的,而不是从一个强大的商业案例。Microservices可以(也应该)得到围绕业务功能和设计重点。好的会再三反省自己要说问自己如果领导的业务需要你考虑microservices,或如果microservices的概念已经在寻宝游戏,你可以应用它。
• 开发团队是跨职能的。如果您的企业有一个敏捷软件开发生命周期,那么你可能已经跨职能团队。这意味着每个人都必须完成的工作在同一个团队,而不是由专业。如果你没有一个跨职能的团队,一个真正的microservices架构可能难以实现。使用跨职能团队开发microservices允许工作完成而不用担心依赖于其他球队。您的业务可以开发、测试、部署、增强和修复microservices在一个团队,导致更大的业务敏捷性。
• 编程语言和平台独立的业务很重要。Microservices可以用许多不同的程序语言编写的。这使得企业选择最适合他们的需求的语言和开发团队的能力。集装箱化,microservices可以部署一个Windows或Linux等任何平台。 单一的应用程序,一旦为平台,设计必须保持在该平台上,除非重新设计。
   
• 数据库可以受益于模块化。的一个好处microservice拥有自己的数据存储,您可以改变数据模式,甚至整个数据库技术而不影响其他microservices。铁板一块,它更难以改变一个数据存储,因为你必须解决所有数据库或表的引用。
• 你是在快速变化的市场,您将受益于快速测试创新假设。了解市场所需要的时间为你的业务敏捷的核心和瀑布的评估。与瀑布开发过程是线性的:详细的规范,其次是设计、编码、测试、返工,然后部署。有时不同群体参与的每一个发展阶段。这使它具有挑战性,如果不是不可能,受益于敏捷microservices可以提供软件解决方案。和敏捷,跨职能团队的工作特性与商业价值最高的短迭代称为冲刺。敏捷软件开发周期,microservices可以开发,全面测试和部署在一个sprint。这允许贵公司作为创新和迅速得到必要的市场反馈。如果一个新特性是决定是必要的,不是已经花了大量的开发时间。如果功能坏了,那么它可以快速固定而不影响生产。如果新功能是有价值的,那么你可以利用这个功能。
• 需要能够满足不断增长的客户期望。客户不会等待6个月或者更多他们需要的特性或bug修复,特别是在竞争和快速变化的市场。Microservices本质上允许贵公司更加的敏捷,这是由于他们的独立功能,允许你的公司成长或改变一个产品来应对市场没有昂贵的交叉设计。
   
• 应用未来发展的需要。知道未来的产品,或者需要灵活的建筑发展/增长可能是一个不错的考虑microservices架构。紧急架构可能会更容易实现,以适应快速变化的市场。

不适合

• 员工没有microservices经验。 如果你的开发团队没有经验或能力来学习如何架构师microservices正确,设计会伤害而不是帮助您的应用程序。
• 不是云。Microservices旨在利用今天的云平台的功能,如可伸缩性。企业仍在数据中心托管应用程序可能不准备microservices。
• 应用程序不需要扩展。如果应用程序不需要扩展现在或将来,然后microservices可能不是必要的。
• 缺乏QA或测试功能。编写良好的应用程序需要测试,microservices也不例外。更健壮的方法测试和支持从整个开发团队需要设计一个适当的microservices架构。
   

缺点

首先,如果你没有一个强大的业务用例实现建筑microservices架构带来的好处,你应该考虑把它放在次要地位。尝试它,如果你有理由认为有一些缺点在做出最终决策之前。

• 增加了复杂性
• 学习曲线
• 运维的开销
• 费用

实现松散耦合和高度凝聚力的microservices,要添加应用程序的体系结构的复杂性。microservices本身和它们之间的通信必须深思熟虑。microservices应用程序,应用程序变得更加复杂。做的不正确,建筑microservices可能不允许你利用他们提供的所有利益。
操作开销增加当从单一的应用程序切换到microservices架构。可能需要时间的好处microservices超过实现他们的运营成本。每个microservice需要自己的资源,从而导致更高的成本在云平台,基于使用的资源。有多个microservices设计模式。 您需要确保正确的模式是选择满足您的需求。
 

总结

microservices方法将应用程序分解成更小、模块化的组件,结合业务功能。这允许应用程序的开发工作直接与业务价值优先的功能一致。
正好适合microservices架构包括需要的应用程序可伸缩性、易于部署、运行要求和需要快速反应,不断增长的客户需求和不断变化的市场条件。
坏适合microservices应用程序不需要扩展或不是由正确的技术支持/能力人们正确地实现它们。
业务敏捷性转化为价值,microservices架构可能是一个不错的选择。然而,决定不应轻易,也只为了技术。应用程序的业务需求或产品应该真正的司机。
虽然microservices是一个伟大的选择增加响应客户需求和不断变化的市场条件下,考虑缺陷,确保投资是适合您的业务。
 

原文：https://ascendle.com/ideas/deriving-business-value-from-a-microservices-architecture/

本文：http://jiagoushi.pro/node/1467

讨论：请加入知识星球【首席架构师智库】或者小号【jiagoushi_pro】或者QQ群【11107777】