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

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

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

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

我们对来自以色列和美国等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

挑战3：组织买入

“获得组织支持可能是最难的部分。” - Steven McCord，ICX Media的创始人兼首席技术官

这不是技术决定。您需要明确说明微服务架构的好处，以说服您的公司重新分配资源。这是一个漫长而乏味的过程，直到组织接受这样的变更，组织越大，决策就越长。

✅可能的解决方案

说服您的组织切换到微服务的最佳方法是将系统中一个非关键部分转换为微服务。通过这种方式，您可以使用真实的工作微服务来展示其优势。

 

挑战4：团队

“最大的挑战发生在团队本身，因为它需要不同的思考。” - Shippable联合创始人兼首席执行官Avi Cavale

开发人员必须花费更多时间来了解什么是端到端场景。 他们需要熟悉技术，可能需要转换思维模式，这需要时间。

对于那些在一个可以进行端到端测试的世界工作的人来说，这是不舒服的，现在你突然将它分解成小块。 这更像是一种文化变革。 （Avi Cavale）

✅可能的解决方案

从非常小的东西开始，您可以从中获益并选择一些不是您应用程序关键部分的东西。 获得一个小团队，将应用程序的这一部分转换为微服务。 证明它实际上更好，并逐步扩展到组织（Avi Cavale）。

避免造成这些错误

 

“避免立即将整个系统切换到微服务。” - Emarsys工程副总裁Andras Fincza

 

“我想你可能犯的最大错误就是你没有对微服务架构的变化所带来的影响进行概述。在实际开始实施新方法之前，您必须包含
许多移动部件。“ - 用户工程副总裁Robert Aistleitner
“使用巨石，可以轻松更改内部界面;您只需重新编译代码并运行测试。使用微服务，您的API必须是黄金。这是依赖，
你不一定了解你的所有客户。在没有API的情况下进行未来验证将在未来产生许多令人头疼的问题。此外，请确保您有
一个分布式跟踪系统。“ - SimilarWeb研发副总裁Daniel Ben-Zvi
“避免在没有弄清平台和依赖关系的情况下尝试切换到微服务。此外，相信微服务是好的，因为每个微服务都可以用
不同的语言编写，这是一种不好的做法。“ - Viktor Tusa，LogMeIn的DevOps工程师
“处理数据至关重要。搞砸数据很容易，但很难恢复。数据迁移应该采取更多步骤。“ - Andras Fincza，Emarsys的
工程副总裁
“在微服务之间共享数据是一个很大的禁忌。如果两个服务正在操纵相同的数据，您将开始遇到一致性问题并消除所
有权的歧义。“ - Daniel Ben-Zvi和Varun Villait
“将应用程序分解成太多太小的部分，或者强迫将系统转换为不应该是微服务的微服务 - 只是因为炒作”.
- Csaba Kassai，Doctusoft的首席开发人员

切换到微服务架构的最佳实践

 

在微服务之间创建隔离使它们能够根据您的需要进行更改。这通常需要在几个层面进行隔离：

1. 运行时进程：这是最明显的，也是通常很快采用的进程。在你有一个过程之前，现在你有很多。这里的主要成本是采用某种形式的分布式计算，这很难做到。这可能会导致您采用容器化，事件体系结构，各种http管理方法，服务网格和断路器。
2. 团队/文化。分离团队，给你自主权，意味着你划分人与人之间的沟通。这往往导致知识孤岛和工作重复（选择性与资源效率选择的结合）。推荐阅读：由Peter Naur编写的理论构建
3. 数据。采用分布式计算方法（如微服务）的最大影响在于它对数据的影响。您已经以某种形式对数据进行了分区，因此您需要在系统级别重新集成它以给人一种“系统”的印象。这为您提供了一些有关扩展的有趣潜在好处，但它还需要更多想到的不是简单的单片数据架构方法。 （大卫道森）

您应该选择哪种技术来获得特定的微服务？

 

这是不同意见开始发生碰撞的地方......

一方面，人们认为使用什么技术和编程语言无关紧要。

“几乎所有问题都可以通过任何技术解决。其他人花费太多时间寻找合适的技术，但如果你以反复的方式做到这一点，
你就有时间思考并看到它在行动中。通过这种方式，可以减轻糟糕的决策。“ - Andras Fincza，Emarsys的工程副总裁
“大多数大型现代语言（Python，Java，C＃，Node / JavaScript）同样快速且可扩展。从这个角度来看，语言并不重要
。每种语言都有其优点和缺点;大多数时候，语言选择是基于个人偏好而不是技术论据。“ 
- Viktor Tusa，LogMeIn的DevOps工程师

 

花费大量时间选择最好的技术是不值得的，因为差异很小。

“选择技术的重要性太高估了。如果运行成本很重要，那么它可以接受，但对我们而言并不重要。“ 
- Andras Fincza，Emarsys工程副总裁
“如果它是一个绿地项目，那么我使用我的程序员最了解的语言。如果它不是一个绿地项目，那么我在
系统中的业务实体使用客户端覆盖范围最广的语言。“ - Viktor Tusa，LogMeIn的DevOps工程师
“微服务的优点是它封装在一个微服务中，只要你提供一个外部微服务接口来与那个东西交谈。
只要他们有接口，我就不在乎。“ - Steven McCord，ICX Media的创始人兼首席技术官

选择合适的技术不仅仅是一个技术问题，也是一个招聘决策。

如果您选择具有10种不同编程语言的微服务架构，则需要确保您的团队能够处理该问题。

“我不建议混合太多的编程语言，因为招聘人员变得更加困难。此外，程序员的上下文切换会降低开发速度。
“ - Usernap工程副总裁Robert Aistleitner
“你必须有意识地选择你想要建立什么类型的开发团队。如果你想使用许多不同的编程语言，你需要建立
一个能够使用和学习不同编程语言的动态团队。“ - Steven McCord，ICX Media的创始人兼首席技术官

一些技术建议：

“我强烈建议在Google Cloud Platform中使用AppEngine等托管服务。从肩膀上承担很多负担。此外，
在选择语言/技术/框架时，为特定的微服务用例选择合适的一个是非常重要的，不要仅仅因为你熟悉它
而强迫某些东西。“ - Csaba Kassai，Doctusoft的首席开发人员

来自Brujo Benavides

另一方面，一些技术领导者很乐意推荐一些技术，这些技术非常适合服务于特定角色的微服务。

在为微服务选择技术时，建议考虑：

• 可维护性
• 容错
• 可扩展性
• 建筑成本
• 易于部署

Brujo团队用于微服务的框架/技术的一些示例：

• Scrapy for web crawling
• Celery + RabbitMQ来传达微服务
• 机器学习部分中的NLTK + Tensorflow（以及其他一些）
• AWS服务

推荐阅读：基于云的应用程序的技术选择案例研究

选择适当技术的过程

 

为您的微服务选择编程语言/技术时，您需要考虑许多事项。

其中一个最重要的事情是了解您的开发人员具备哪些能力以及语言/技术背后的支持（工具，社区......）。根据我
的经验，公司倾向于根据其开发人员的能力选择一种编程语言。“ - Csaba Kassai，Doctusoft的首席开发人员
“使用拥有大量支持（资源和活跃社区）的技术。我会推荐Ruby和JavaScript，因为你得到了很多支持，如果出现
任何问题，很多人都会帮助你。我想只要你确保有很多人使用它，承担一种语言应该不是问题。因为在这种情况下，
如果您的团队不具备这些知识，您可以依赖外部资源。“ - 工业首席执行官Varun Villait
“另一个因素可能是存在一种可用于加速项目的语言库。你理想的语言选择可能没有你可能需要自己发明的某些
东西的库，这可能是另一个时间流失。显然，容错和可扩展性等问题也应该是一个重要因素。如果你不得不在几
个月后从头开始重新编写一些东西，因为最初的选择无法扩展，那么你最好先咬一口。我认为这一切都取决于
具体的团队情况以及他们愿意做出的投资。“ - Greg Neiheisel，天文学家联合创始人兼首席技术官

这是EMARSYS的流程：

在Emarsys，如果他们想要应用新的编程语言，开发人员需要提供真实的逻辑原因并咨询主要开发人员。团队聚集在一起讨论技术的优缺点。

他们总是使用不同的技术创建一个尖峰解决方案。这使他们可以尝试给定技术的边界，看看它是否可以应用于给定的微服务。这非常适合揭示技术的局限性。

“建议使用您的团队已经熟悉的语言。通过这种方式，他们可以更舒适地工作，并且进步更快。“ - Andras Fincza，Emarsys的工程副总裁

这是他们在SIMILARWEB的做法：

作为一家大型数据和分析公司，我们应对非常大规模的挑战，这会增加选择错误技术的风险和影响。单个线程框架（如NodeJS）虽然适用于网络绑定服务，但在处理实时密集型数据处理时无法扩展。

工程师通过平衡战术和战略需求以及查看技术和组织约束来确定使用哪种技术。我们处于快速原型设计阶段吗？该服务是否处理大量数据？我们是否想要在我们的堆栈中添加新技术，因为我们相信它的生态系统还是我们使用已经掌握的现有技术？我们想要实验吗？我们能找到对此充满热情的工程师吗？我们是否愿意长期致力于这项技术？技术生态系统是一个主要因素。我们希望与开源社区合作，而不是重新使用和贡献现有框架，而不是重新发明轮子。

一般来说，我们不希望传播得太薄;否则，你没有获得专业知识。

定义明确的指导方针，甚至是清单，可以帮助促进健康的决策过程，并缩小可能的技术选项，以选择最适合您的团队和产品的选项。

DAVID DAWSON对选择技术的建议：

1. 从数据架构的角度来看，您需要能够提供数据的东西，您可以轻松地在服务之间通过网络同步到一致的可用状态。有各种各样的方法，这是我在微服务部署中实际寻找的方法。因此，您可以观察实现这些模式的各种框架和技术（这是Kafka，Spring Data Flow，Akka和朋友等技术人员所在的地方）。
2. 一旦我们确定了这些模式和方法，您就可以使用您可用的资源进行网格化。如果您已经决定使用大量反应式编程的数据流方法，并且您已经拥有Java开发人员，那么选择Spring，Spring Cloud Data Flow和Kafka是有意义的，并且可能部署到某种形式的Cloud Foundry（如果你可以得到它！）。

如果您需要大量较重的数据转换，请引入Spark或Kafka Streams来帮助解决这个问题。如果你有JavaScript开发人员，那就没有意义了。相反，你会在JS运行时（clojurescript等）上采用一些函数式语言，再次使用一些类似的反应式集成技术（Kafka肯定会在这个空间中制造波浪）并从中获取它。

关键要点：

1. 不要强调选择完美的技术。 采用迭代的实验方法代替。
2. 每个微服务架构都是独一无二的; 选定的技术应与系统的需求保持一致。
3. 请记住，太多不同的技术使招聘更加复杂。

结论

在切换到微服务架构时，存在许多挑战。

在开始将系统转换为微服务之前，请确保有真正的理由说明为什么要这样做。了解优势和劣势可能会有很大帮助。您不必遵循最新的炒作，而是首先考虑系统的独特功能，而只是改变最容易受到伤害的系统部分。不建议从头开始使用微服务架构，因为很难明确定义微服务的边界。

如果您决定切换到微服务，请采用增量方法并取出系统中一个非常关键的小部分，以了解其工作原理。这也是获得组织支持以创建更多微服务的好方法。

没有一种最佳方法可以为微服务选择完美的技术。每项与技术相关的决策都会受到您团队当前知识以及公司未来招聘计划的影响。在某些情况下，为微服务选择技术更多是招聘决策，而且取决于您希望在未来构建哪种类型的开发人员团队。

为了缩小可能的技术，来自Emarsys的Andras Fincza，来自SimilarWeb的Daniel Ben-Zvi和David Dawson提供了一个可以轻松应用的简短流程。

渴望更多？

4软件团队的有效知识转移方法

招聘开发人员是一个挑战吗？以下是科技公司如何应对它

优先考虑软件开发需求的科学方法