切换到微服务架构似乎很容易，但技术领导者倾向于低估项目的复杂性并犯下灾难性的错误。

在将单片系统转换为微服务或从头开始之前，您需要仔细考虑将要出现的技术和组织挑战。

如果您想要，这篇文章适合您：

• 从单片系统切换到微服务。
  
• 从经验丰富的技术领导者那里收集见解。
  
• 了解微服务的缺点和优点。
  
• 避免灾难性的错误。
  
• 对微服务做出更好的技术决策。
  

我们对来自以色列和美国等5个不同国家的技术领导人进行了13次采访，然后将他们的知识压缩到这个可操作的帖子中。

这篇文章真的很长！您可以使用以下链接跳转到特定部分：

• 了解你的原因
  
• 明确定义微服务是什么
  
• 微服务架构的优点和缺点
  
• 最大的微服务挑战和解决方案
  
• 避免犯这些错误
  
• 切换到微服务架构的最佳实践
  
• 您应该为特定的微服务选择哪些技术？
  
• 选择适当技术的过程
  

了解你的原因

您可以犯的最大错误是在没有明确目标的情况下切换到微服务架构。您需要了解并有真正的理由说明为什么要这样做。

“人们盲目地做了很多事情：哦，码头很酷，微服务很棒！它可能不适合您构建的每件作品，您需要了解为什么要这样做。“ - Steven McCord，ICX Media的创始人兼首席技术官

如果你的工作系统运行良好，那你改变它的动力是什么？

仅仅因为微服务被大肆宣传并不意味着你需要加入这个潮流。它可能不是您软件的最佳技术选择。

确定原因至关重要;这就是David Dawson，Steven McCord和Avi Cavale所强调的。

“当我们的客户要求我帮助他们实施微服务时，我问的第一个问题是，为什么？我正在寻找的答案是，“我们希望更快地改变我们的系统”和“我们希望利用云技术。”我让他们意识到，做得对的微服务比构建单片系统更昂贵，更难。它为您的数据做了有趣的事情，并在您的数据模型中引入了一个网络，可以随时任意分区，数据丢失。你让自己暴露在分布式计算的全面愤怒之中。“ - David Dawson，系统架构师

推荐方法：

• 西蒙·沃德利的沃德利地图
  
• Gojko Adziks的影响映射
  

明确定义微服务是什么

“我不一定会选择微服务。我会选择中型服务，所以不是从单块服务到数百种服务，而是更大的服务，与工程团队和业务垂直市场保持一致。“ - DanielWeb研发副总裁Daniel Ben-Zvi

如果您在服务，微服务和功能之间找不到适当的平衡，您可以：

• 对您的应用程序进行细分，这样您就不会看到微服务的好处。
  
• 过度分割您的应用程序，这意味着管理微服务本身的重量将破坏微服务可以提供的价值（Avi Cavale）。
  

对于微服务特性如何为您的公司寻找一个非常明确的理念至关重要。

你怎么做呢？微观案例研究

“我们通过查看代码片段来确定微服务是什么，如果更改，最终会创建指数测试用例。我们开始解决这些问题是因为我们的目标是减少我们为每一项改变所做的测试。如果这是你的目标，那么你定义为微服务的方式与有人说“我希望计费成为微服务”不同。“ - Seippable联合创始人兼首席执行官Avi Cavale

推荐阅读：微服务与单片架构

微服务架构的优点和缺点

微服务的优点

• 可扩展性：您可以分析小块，以查看每个部分的要求。它使您可以单独扩展应用程序的不同部分。
  

“对我来说，另一大好处是我可以在任何VM之外扩展这些容器。我可以将容器放入我想要的任何配置中，这样我的应用程序就可以完全移植。“ - Steven McCord，ICX Media创始人兼首席技术官

• 更易于维护：让不同的团队以或多或少的独立方式处理不同的组件。
  
• 部署和配置没有太多干扰：您可以部署和配置系统的微小部分，而不会影响其他服务。多个团队可以为生产提供多种结果，而不会干扰和踩到彼此的脚趾。
  
• 问题隔离：更容易隔离和检测问题。
  
• 更容易招聘：当您正在寻找开发人员或第三方提供商时，您只需要为系统的一小部分进行培训。
  
• 责任明确定义：一个团队负责给定的微服务。
  
• 深刻的知识：从事内部工作的团队从内到外都知道。
  
• 各种各样的编程语言：您可以使用不同的编程语言，具体取决于最适合微服务的目的。
  
• 更容易监督和理解：您可以将庞大的代码库拆分为较小的项目。这种方法可以让您和您的团队更好地理解项目及其代码。
  
• 更容易打开组件：当明确定义边界和接口时，更容易向新业务单元或外部实体打开组件或现有功能。
  

微服务的缺点

• 部署和互操作性：缺点是部署和互操作性成为主要问题。
  
• 编程语言太多：这可能会限制代码的可重用性和可维护性，并且可能会使招聘变得更加复杂。
  
• 使组件协同工作：您始终需要确保以他们协同工作的方式组合您的服务。只需考虑更改单个端点，这会破坏旧版本中的其他依赖服务。
  
• 与整体系统相比，整个系统的集成测试更难，一切都在一个地方。
  
• 从一开始就必须仔细考虑架构：如果服务之间存在太多的凝聚力，那么即使不是所有优势，也会失去最多。
  
• 需要更多的沟通工作：在服务之间的沟通方面，您需要进行相关的投资。在服务通信之间可能发生很多失败。
  
• 难以监控整个系统：你有很多碎片可能是一个噩梦来监控。
  
• 需要时间学习：使用微服务需要学习，这需要时间。
  
• 复杂性：拥有越来越多的微服务，使整个系统更加复杂，更难以监督整个操作。
  

“所有这些作品都在四处闲逛。如果你没有非常好的工程流程，那么你最终将会遇到许多根本无法使用的东西。“ - Seippable联合创始人兼首席执行官Avi Cavale

“在基于微服务的平台上调试生产问题是一个完全不同的歌剧。如果没有适当的监控，日志记录和跟踪设施，系统的复杂性就会显着增加。这就像穿过迷宫一样。工程实践和标准化变得至关重要。“ - DanielWeb研发副总裁Daniel Ben-Zvi

• 登录到一个地方很有挑战性。像Loggly，Splunk或Heroku这样的第三方日志聚合服务是非常好的解决方案，但它们确实以非常高的价格出售。根据我的经验，遥测专门集中测井是一个最大的痛苦。您必须考虑每项服务的详细程度。如果不这样做，您最终可能只需支付50-60％的费用来记录下文。 （微软网站可靠性工程师Sonu Kumar）
  

最大的微软服务挑战和解决方案

在转向微服务时，这些是技术领导者和开发团队可能面临的最大挑战。

• 挑战1：立即切换系统
  
• 挑战2：拆分系统
  
• 挑战3：组织支持
  
• 挑战4：团队
  

挑战1：一次性切换你的系统

“从单片架构切换到微服务架构并不是你可以同时做到的。如果您有一个单片服务器，那么您可能拥有存储库，部署任务，监视以及围绕它紧密设置的许多其他内容。改变这一切并非易事。“ - Bruaka Benavides，Inaka的前首席技术官

“如果一家公司从未有过使用微服务的经验，即使是绿色的现场项目也会比他们想象的更难。” - LogMeIn的DevOps工程师Viktor Tusa

✅可能的解决方案

我们当时所做的是保持整体服务器的位置，但任何新的添加都是作为微服务开发的，所以最终事情从原始服务器中消失，直到它最终成为我们最老和最大的微服务。 （Brujo Benavides）

挑战2：分裂系统

如果组件和服务从项目开始就粘在一起，那么隔离组件和服务可能非常具有挑战性。 （Robert Aistleitner）。

您需要定义各个部分之间的交互和流程。 如果您没有以良好的方式定义，您的系统将产生更多问题。 （StyleSage高级开发人员Jose Alvarez）

“没有模式; 将系统拆分成微服务有很多不同的规则，但没有人会告诉你如何在你的应用程序中这样做。 没有两个相同的微服务。“ - Recart首席架构师David Papp

✅可能的解决方案

“将单片系统拆分为微服务的唯一方法是首先检查单片系统，看看它最痛”的地方。 系统的这些部分应该被取出并转换成微服务。“ - Andras Fincza，Emarsys的工程副总裁

如果您没有适当监控，您将无法看到系统的工作方式。监控所有部件的工作情况以及他们正在做的事情。如果您监控系统，则可以轻松检测并解决问题。 （何塞阿尔瓦雷斯）

逐步增加，逐个模块是拆分单片系统的最佳方式。如果你想一次做所有事情，你肯定会失败。

监控工具提示：

• New Relic
  
• Datadog
  
• Influxdb
  
• Grafana