「微服务架构」七种微服务反模式
什么是微服务
流行语经常为进化的概念提供背景，并且需要一个良好的“标签”来促进对话。微服务是一个新的“标签”，它定义了我个人一直在发现和使用的领域。文章和会议描述了一些事情，我慢慢意识到，过去几年我一直在发展自己的个人经历。虽然有关微服务的行业和专业讨论已经成为Netflix，亚马逊和谷歌等公司以及成功完成这项工作的从业者的焦点，但我有一些个人经验可以为成功的微服务实施提供见解。
任何架构的三个标准和最常见的业务驱动因素是：
- 提高敏捷性 - 及时响应业务需求以便业务增长的能力
- 改善客户体验 - 改善客户体验，从而减少客户流失
- 降低成本 - 降低添加更多产品，客户或业务解决方案的成本
事实上，我们所有人都在努力在日常工作中这样做。 SOA创建了一个业务一致的软件框架，使企业能够实现这一目标。几家大型软件供应商已经出现并声称他们的产品套件可以使企业提供SOA。
如果您没有合适的人员，文化和投资，SOA将无法实现业务价值。微服务架构与SOA并没有根本的不同，目标和目标是相同的，但是方法略有改进，事实上，我只是说微服务仅仅是SOA可扩展的。微服务使应用程序/系统迫切需要从单一实现转移到服务于许多应用程序的分布式分散服务平台。微服务是独立的，它将敏捷性和应用程序演变视为企业数字化转换。微服务的成功取决于服务独立性和服务灵活性。
我将微服务定义为“通过构建细粒度服务以支持分布和组织为功能域的业务功能来提供SOA的方法”。没有模式是魔术棒或银弹。您应该正确构思和定制模式企业应该专注于解决支持架构所需的项目以构建自适应平台。
一些企业的SOA实施失败了 - 因为他们没有完全分析他们的业务能力模型，并认为开发Web服务意味着SOA或从大型供应商购买SOA套件会使他们启用SOA或无法显示SOA及其业务驱动因素/目标。
举例
经验的一个例子可能会澄清这一点。在过去的一份工作中，该企业的目标是提高敏捷性，客户体验并降低成本。我们决定构建一个标准的多租户SOA平台。该方法旨在开发细粒度的服务，以便我们可以经常进行更改，并为平台部署小的，可管理的更改。如果我们今天采用相同的方法，我们可能会称之为微服务架构。那时我们没有这个词，但它才有意义。
服务是基于业务能力模型建模的，第一个版本进展顺利。它们是基于JMS同步服务的XML，主要侧重于提供向代理，Web和语音通道应用程序公开的声明平台所需的功能。它使我们能够为我们的应用程序无缝部署频繁，小的更改和A / B功能支持。
当需求逐渐增加（并且它们总是如此）时，由于应用程序和消费者之间的集成复杂性，很难快速发布解决方案。集成，功能测试和生产发布需要紧密协调。随着业务开始扩展，更改频率比初始版本高出10倍，并且由于交付生命周期中的大多数任务都是手动的，因此上市时间不符合业务预期。很快，由于糟糕的微服务自动化和生命周期管理导致交付熵，我们的目标都没有实现。
经验教训 - 不要做这些事情，而是......做其他事情
这让我分享了我在旅途中学到的一些课程，以便您在使用微服务上路时能够密切关注这些项目
- 1）凝聚力混乱
我们开发了一项服务，以获取客户信息，旨在提取客户政策信息，个人信息和他们注册的计划。一段时间以来，它开始做的不仅仅是获取客户信息。随着新要求的出现，该服务经历了频繁的更改和部署。它无法扩展并满足所需的可用性。它成了众所周知的“泥球大球”。它是怎么到达那里的？对于初学者来说，没有关于功能性关注分离的治理。如果一个有影响力的消费者要求在这一项服务中加入不相关的逻辑来减少往返行程，那么这个功能就毫无疑问地被打了。也许网关或BPM层本可以避免这种情况，但是没有时间......只是时间来制定另一个业务功能点。
预防性治疗是为了管理与服务无关的业务功能。服务必须与业务能力明确对齐，不应试图在其边界之外做某事。关注的功能分离对于架构管理至关重要，否则会破坏敏捷性，性能和可伸缩性，最终建立紧密耦合的架构，导致传递熵和内聚混乱。
- 2）不认真对待自动化
我们没有自动部署策略和ops服务监控（运行时QoS指标）。它显然增加了部署期间的运营费用和手动错误。多次生产部署导致配置错误导致中断。这些服务始终以HA模式部署，因此容器数量是服务总数的3倍。操作团队无法手动处理每项服务的配置。经过一段时间后，操作人员开始抱怨架构效率低下，因为他们无法处理增加的容器数量。
这是什么疫苗？配方有多种成分。如果您还没有这样做，持续部署是每个企业都应该追求的必须投资和文化变革。至少，如果你没有办法自动测试和部署 - 不要做微服务。微服务的目标是以我们需要改变的速度来提高敏捷性;质量保证涉及每项服务都具有自动化单元，功能，安全性和性能测试。当我们开发与我们无法控制的服务集成的服务时，服务虚拟化是另一个强大的概念。
- 3）分层服务架构
人们用SOA做出的一个常见错误是误解了如何实现服务的可重用性。团队主要关注技术凝聚力，而不是关于可重用性的功能。例如，若干服务用作数据访问层（ORM）以将表公开为服务;他们认为这将是高度可重复使用的。这创建了由横向团队管理的人工物理层，这导致了交付依赖性。创建的任何服务都应该是高度自治的 - 意味着彼此独立。
创建多个技术，物理层的服务只会导致交付复杂性和运行时效率低下。我们最终拥有包装服务，编排服务，业务服务和数据服务。这些服务模型提供了技术问题。各个团队成立以管理这些层，最终导致业务逻辑蔓延，没有单一的业主能力，失去效率，总是有一个责备游戏。
服务中的层的逻辑分离很好，但是，不应该有任何进程外调用。尝试将服务视为一个原子业务实体，它必须实现一切以实现所需的业务功能。自包含服务比分层服务更具自主性和可扩展性。在多个服务中重写一些常用代码是完美的，这很好，并且保持自治级别是一个很好的权衡。最重要的是，没有技术问题分开的服务，而是必须根据业务能力将它们分开。由于这种特性，集装箱化的概念正在蓬勃发展。
- 4）依靠消费者签字
我们有来自三个不同渠道的多个应用程序所消耗的服务，即代理，网络和语音。代理渠道是我们的主要渠道，因此服务必须等待他们在投入生产之前签字。它延迟了语音和Web应用程序的生产版本。是什么将这三个通道紧紧地联系在一起？
当涉及通道特定功能时，该服务不是松散耦合的。为您的服务提供独立性。您提供的每项服务都必须具有测试套件，该套件应涵盖所有当前和未来消费者的所有服务功能，安全性，性能，错误处理和消费驱动测试。这必须作为自动回归测试的构建管道的一部分包含在内。
- 5）手动配置管理：
当我们开始做大量服务（并且由于缺乏服务生命周期治理而导致的不可避免的蔓延表现）时，管理每个服务的配置失控。由于密码错误，URL错误，值不正确等配置失败，我们的大部分生产部署都不顺利。手动管理这些变得越来越难。如果我们只使用应用程序配置管理工具作为PaaS或CD的一部分......但我们没有。
6）版本避免：
天真地，我们认为只需要一个版本的服务。然后我们开始添加主要的次要版本以适应多个消费者和频繁的变化。最终，每个版本都必须是主要版本，因为服务依赖于消费者签名。结果，容器的数量增加得非常快，并且管理它们变得非常痛苦。缺乏运行时治理是导致此问题的另一个方面。有些企业愚蠢地试图避免版本控制。假设变更是不可避免的，需要对服务进行架构。制定策略来管理向前兼容的服务更改，并让您的消费者优雅地升级。否则，它将导致消费者紧密绑定到服务版本并在发生更改时中断。
随着微服务世界所期望的服务数量的增长，复杂性也在增长。有一个版本控制策略，可以让消费者进行优雅的迁移，并确保提供商可以透明地部署更改，而不会影响任何人。限制生产中并排主要版本的数量并管理它们。
- 7）在每个服务中构建网关
我们没有API网关，我们没有运行时治理（我们不知道谁在什么时间消耗什么以及以什么速度消费）。我们开始在每个服务中实现最终用户身份验证，限制，协调，转换和路由等。它增加了每个服务的复杂性，并且我们失去了从服务到服务的实现的一致性，因此我们不知道谁实现了什么和哪里。最重要的是，我们的一些服务是为满足一个消费者的非功能性需求而构建的，而不是另一个。如果我们有一个网关，应用一些数据过滤和丰富模式就可以做到。要是。
投资API管理解决方案，以集中，管理和监控一些非功能性问题，并且还可以消除消费者管理多个微服务配置的负担。可以使用API网关编排可以减少Web应用程序往返的跨功能微服务。
结论
微服务的目标是解决三个最常见的问题，即改善客户体验，高度敏捷地满足新要求，并通过将业务功能作为细粒度服务来降低成本。这不是一个灵丹妙药，需要一个规范的平台，以高质量的敏捷方式提供服务。从其他错误中学习（我的）并避免在架构和交付过程中列出的上述模式。这是我们谈论集装箱化，云采用等之前的第一步。我希望本文能为您的企业提供一些思考，并在将这些反模式编织到您的架构之前解决这些反模式。大多数项目将推动组织内部的文化变革，不能仅靠自己完成，确保与您的高管和高级领导者建立伙伴关系。