反模式如何扼杀企业中微服务的采用
摘要
对于将其架构迁移到微服务的公司而言，反模式可能是成功的主要障碍。 这是识别和避免它们的方法。
在我的上一篇文章《帮助大型企业加快开发，部署和扩展的微服务模式》中，我们介绍了一些部署和通信模式，这些模式可以在您使用更多微服务时使它们保持可管理性。 我还承诺，在我的下一篇文章中，我将探讨微服务模式如何变得有毒，造成更多的开销和不可靠性以及变得难以管理。 因此，让我们深入。
第一件事：模式很棒。
它们有助于将创意形式化为可重用的块，您可以将其分发并轻松地与团队进行沟通。 以下是模式可用于各种规模的工程部门的一些有用的事情：
- 使思想散布
- 降低初级成员成功的障碍
- 创建构建基块
- 在不同/复杂的系统中创建一致性
模式通常是故意行为。 当我们采用适当的模式时，我们将做出明确的选择，并做出使事情减轻痛苦的决定。 但是，并非所有模式都有用。 就反模式而言，它有可能给工程团队和企业带来更多麻烦。
反模式的剖析
像模式一样，反模式也易于识别和重复。
反模式很少是有意的，通常您可以在看到反效果后很长时间就将它们识别出来。 为了追求更快的交付速度，赶紧的最后期限等，组织中的个人通常会做出善意的选择（如果不好的话）。 这些反模式通常由其他员工保留，他们决定：“嗯，这一定是在这里完成的方式。”
这样，反模式会成为非常危险的规范。
对于想要将其架构迁移到微服务的公司而言，反模式是成功的严重障碍。 这就是为什么我想与您分享一些常见的反模式，我在使用微服务的公司中已经看到过很多次了。 这些举动最终损害了他们的进步，并造成了他们试图避免的更多问题。
数据太妃糖
第一种反模式是在它造成的混乱和破坏中最常见，也是最微妙的。
问题
数据太妃糖反模式可以几种不同的方式体现，但是简短的解释是，当所有服务都可以完全访问数据库中的所有对象时，就会发生这种情况。
听起来还不错，对吧？
您希望能够创建跨多个域的复杂查询和复杂数据输入方案。 因此，乍一看，让所有内容直接从数据库中调用需要的东西是有意义的。 但是，当您需要扩展应用程序中的单个域时，这就是一个问题。 数据很少在所有域中均匀地增长，而是在单个域中突发地增长。 有时很难预测哪些域将增长最快。 纠缠在一起的数据变得像太妃糖一样：很难拆开。 它伸展并卡在业务中。
在这种情况下，公司将拥有许多存储过程，跨许多服务的嵌入式复杂查询以及所有访问数据库的对象关系管理器，每一个都对如何“使用”域有自己的了解。 这几乎总是导致数据污染和性能问题。
但是，挑战甚至更大，尤其是当您需要对数据库进行结构更改时。
这是一个基于我在一家大型私有公司中的现实生活经验的示例，该公司从小公司起家，Swift发展为成千上万的客户提供服务。 假设您有一个表，其主键是一个从0开始的int。在没有键之前，您有2,147,483,647个对象-没什么大不了的，对吧？
因此，您开始构建服务，此表成为应用程序中的基石对象，每个其他域都以某种有意义的方式进行接触。 在不知不觉中，有125个应用程序从查询或存储过程中调用该表，总共有13,000个对该表的引用。 因为这是核心表，所以它会获取大量数据。 很快，您将拥有2,100,000,000个对象，每天新增10,000,000个新记录。
您需要四天的时间才能解决问题-真的很糟糕。
您尝试添加负值来购买时间，但没有意识到一半的服务具有ID必须大于0的硬编码规则。因此，您硬着头皮，手动遍历每个服务以查找已创建的每个对象的每个实例使用此数据，然后将类型从整数更新为大整数。 然后，您必须使用外键关系更新其他几个表，对象和存储过程。 所有人都在疯狂地试图阻止公司的旗舰产品成为DOA，这成为了巨大的痛苦。
显然，对于任何公司而言，这都不是理想的方案。
现在，如果此域包含在单个服务的后面，您将确切知道该表的使用方式，并且可以找到有创意的解决方案来保持向后兼容性。 毕竟，您可以通过更改数据库中的数据值来完成很多您根本做不到的代码。 例如，在上面的示例中，大约有8亿个可用ID可以回收并映射到新添加的ID，这将为长期计划购买足够的时间，而该计划不需要疯狂的全力以赴。甲板方法。 甚至可以将其与基于用于有效分区数据的辅助值的两键系统结合使用。 另外，我们可以使用一个可分区的字段为我们提供10,000倍更多的可用整数，以及一个五年的窗口来创建更永久的解决方案，而无需更改任何使用的服务。
这只是一个轶事，但是我已经看到了这个问题，在公司处于关键增长时期时，它一直在暂停公司的规模战略。 因此，请尽量避免使用这种反模式。
怎么解决
要解决数据传输问题，必须将数据隔离到只能通过旨在为其服务的服务访问的特定域。 数据可能在同一数据库上开始，但是使用架构和访问策略来限制对单个服务的访问。 这使您可以更改数据库，创建分区或移动到全新的数据存储系统，而无需了解或关心其他任何服务或系统。
依赖性障碍
假设您已切换到微服务，但部署所需的时间比以往任何时候都要长。 您希望您从未尝试分解整体 。 如果听起来很熟悉，则可能是您患有依赖性障碍。
问题
依赖性障碍是最容易检测到的反模式之一。 如果您必须知道必须部署服务以防止它们失败的确切顺序，那么这很明显地表明，依赖项已经以无法很好扩展的方式嵌套。 依赖关系紊乱通常来自于域从一个域的堆栈横向调用到另一个域（而不是从UI到网关的堆栈向下调用），然后再调用启用该网关的服务。 由依赖关系混乱引起的另一个大问题：未知的执行路径需要花费很长时间才能执行。
怎么解决
APM解决方案是解决依赖障碍问题的一个很好的起点。 尝试利用提供服务执行路径完整拓扑的解决方案。 通过利用这些映射，您可以精确地削减呼叫链并重新调整网关的位置，以进行异步执行而不是进行横向呼叫的扇出呼叫。 有关有用模式的一些示例，请查看本系列的第一部分 。 理想情况下，我们要避免“服务到服务”呼叫会产生深层次且难以管理的呼叫堆栈，而希望网关提供更多呼叫。
微石
微石基本上是善意的，清晰的服务路径，将依赖关系置于最大熵状态。
问题
想象一下，您有一个真正经过精心设计的服务，数据库和网关实现，您决定将其隔离到一个容器中，感觉真好！ 您对数据的存储，管理和扩展有一套整齐的规则。
相信您已经达到了微服务的必杀技，就松了一口气，等待获得嘉奖。 然后您会发现发行版逐渐开始花费的时间越来越长，并且数据耦合正在以奇怪的方式发生。 您还会发现自己几乎在每次部署中都部署了整个服务套件，从而导致测试问题和延迟。 每个季度都会出现越来越多的故障单，在您不知不觉中，该组织已准备好完全废弃微服务。
微服务的承诺是没有规则-您只需提供所需的内容即可。 问题在于，如果没有明确定义数据如何沿堆栈向下流动，您基本上会在数据太妃糖和依赖障碍之间造成混合问题。
怎么解决
此处的调解过程实际上与依存障碍相同。 但是，如果您使用的是成熟的微石，则需要花费一些精力才能恢复到稳定的状态。 我能提供的最佳建议是，尽力达到可以在提交时立即部署提交的地步。如果自动化和依赖关系的订单安排得当，新的服务功能应始终准备就绪，可以尽快部署。开发人员致力于代码库。 不要站在形式上。 如果此过程很麻烦，请执行更多操作。 简化自动化测试和部署，以便您可以可靠地将提交部署到生产中，而无需停机。
最后的想法
我希望这会引起您对您现在可能面临的微服务挑战或将来的挑战的担忧。 这些信息全部基于我的个人经验，以及我与业内其他考虑这些问题的人的日常对话。 我也很想听听您的意见。 通过电子邮件（ [email protected]）与我们联系 ； Twitter， https：//twitter.com/ChaseAucoin ； 或LinkedIn， https：//www.linkedin.com/in/chaseaucoin/ 。 如果您还有其他想法，我希望收到您的来信！
翻译自: https://www.javacodegeeks.com/2018/09/anti-patterns-stifle-microservices-adoption.html