如何在迁移到微服务时避免共同的挑战

根据本周“API世界”2017年的发言人，迁移到微型服务需要进行重大的技术改造。在这篇文章中，两位微服务专家Irakli Nadareishvili和Chris Tozzi揭露并提供了两个常见的建议技术微服务挑战。

总部位于美国弗吉尼亚州麦克莱恩的Capital One技术高级总监Nadareishvili表示：“了解如何构建微服务体系结构可能会很痛苦，就像任何其他重大转型一样。” 他在API世界2017年会议上阐述了“在首都一实施微服务”。

Nadareishvilli和Tozzi为迁移到微服务中的两个最常见的技术错误提供了替代方案：不适当地解耦分布式系统，而不是调整微服务器的大小。Tozzi是加利福尼亚州利弗莫尔的Fixate IO DevOps分析师。

技术挑战1：不松散耦合

Irakli Nadareishvili

Nadareishvili不是建立微服务架构，而是看到公司创建了一个分布式的整体，组织不能在不影响另一个服务的情况下改变一个服务。这违背了微服务架构的格局，这应该减少系统之间的协调。

在最坏的情况下，Tozzi指出，组织必须运行和管理作为不同服务部署的应用程序，但这些服务仍然相互依赖。“例如，您可能有一个前端服务，只有在连接到以某种方式配置的数据库时才起作用，”他解释说。反过来，该数据库期望以特定的方式配置前端服务。“如果您没有将应用程序分发到独立服务中，那么您仍然可以运行一个单一的服务器。”

克里斯·托齐

Nadareishvili建议使用他的“ Tw。规则”来避免某些情况下的耦合，作为避免创建分布式巨集的一种方式。这种做法要求确保基础架构至少支持两个关键组件的替代方案。

Tozzi说，在迁移到微服务时总是认为“ 松散耦合 ”，而不坚持SOA模型。他说：“避免分布式整体反模式的最佳方式是确保您的应用程序中的每个微服务都能独立于其他应用程序启动和运行。” “每个服务的配置也应该是独立的，能够被修改而不影响其他服务或应用程序。”

微服务挑战第2号：权利大小

在与DevOps团队合作的过程中，Nadareishvili表示，他认为他们正在努力寻求如何正确规模的微服务。他们通常不确定微服务应该如何微。

Nadareishvili说，一个选择是使用域驱动设计（DDD）有界的上下文作为尺寸指南。但是，这种方法有两个主要问题：

• 使用DDD调整微服务仅在早期阶段才起作用。这意味着微服务器的完美大小不存在。微服务器的正确大小是时间的函数; 尺寸随时间而减小。Nadareishvili解释说：“随着团队在微服务实践中的成熟以及对其问题领域的了解，更大的微服务通常会分散，整体粒度增加。
• 即使在早期阶段，使用正式的DDD也很困难。它需要一些专业知识和经验。Nadareishvili说：“我已经遇到了更多的团队，意识到DDD比实际上练习的团队。“我认为原因是正式的[和]常规DDD分析的复杂性。

使用事件风暴的一个棘手的部分是最终的工件不可能以任何合理的方式捕获。最后的神器Nadareishvili说，是很长的纸条，其上有数百种“粘性”。当他的团队经过一个事件强攻练习，他所使用的微服务设计画布从API学院捕捉的最终设计。该工具用于在开发之前识别服务的所需属性。“这两个组合工具对我们来说真的很好，”他说。Nadareishvili建议使用有限的上下文来初步调整微服务。除此之外，他还说，使用组合建模技术（事件风暴）来发现它们，而不是更传统的DDD方法。Nadareishvili表示：“我对于微观服务以及一般领域了解领域的事件都是一大热门话题。他建议任何风格的建筑。“它为产品所有者和技术团队之间共享的问题领域带来无与伦比的理解。”

微服务挑战底线：减少协调

专家说，要注意什么导致你的系统协调。查找和删除这些耦合将加速迁移到微服务器。Nadareishvili总结说：“微服务架构主要是为了减少协调需求。“其他一切都是次要的。”

作者：Jan Stafford

原文：http://searchmicroservices.techtarget.com/news/450427289/How-to-avoid-common-challenges-when-migrating-to-microservices