挑战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的首席开发人员
切换到微服务架构的最佳实践
在微服务之间创建隔离使它们能够根据您的需要进行更改。这通常需要在几个层面进行隔离：
- 运行时进程：这是最明显的，也是通常很快采用的进程。在你有一个过程之前，现在你有很多。这里的主要成本是采用某种形式的分布式计算，这很难做到。这可能会导致您采用容器化，事件体系结构，各种http管理方法，服务网格和断路器。
- 团队/文化。分离团队，给你自主权，意味着你划分人与人之间的沟通。这往往导致知识孤岛和工作重复（选择性与资源效率选择的结合）。推荐阅读：由Peter Naur编写的理论构建
- 数据。采用分布式计算方法（如微服务）的最大影响在于它对数据的影响。您已经以某种形式对数据进行了分区，因此您需要在系统级别重新集成它以给人一种“系统”的印象。这为您提供了一些有关扩展的有趣潜在好处，但它还需要更多想到的不是简单的单片数据架构方法。 （大卫道森）
您应该选择哪种技术来获得特定的微服务？
这是不同意见开始发生碰撞的地方......
一方面，人们认为使用什么技术和编程语言无关紧要。
“几乎所有问题都可以通过任何技术解决。其他人花费太多时间寻找合适的技术，但如果你以反复的方式做到这一点，你就有时间思考并看到它在行动中。通过这种方式，可以减轻糟糕的决策。“ - 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对选择技术的建议：
- 从数据架构的角度来看，您需要能够提供数据的东西，您可以轻松地在服务之间通过网络同步到一致的可用状态。有各种各样的方法，这是我在微服务部署中实际寻找的方法。因此，您可以观察实现这些模式的各种框架和技术（这是Kafka，Spring Data Flow，Akka和朋友等技术人员所在的地方）。
- 一旦我们确定了这些模式和方法，您就可以使用您可用的资源进行网格化。如果您已经决定使用大量反应式编程的数据流方法，并且您已经拥有Java开发人员，那么选择Spring，Spring Cloud Data Flow和Kafka是有意义的，并且可能部署到某种形式的Cloud Foundry（如果你可以得到它！）。
如果您需要大量较重的数据转换，请引入Spark或Kafka Streams来帮助解决这个问题。如果你有JavaScript开发人员，那就没有意义了。相反，你会在JS运行时（clojurescript等）上采用一些函数式语言，再次使用一些类似的反应式集成技术（Kafka肯定会在这个空间中制造波浪）并从中获取它。
关键要点：
- 不要强调选择完美的技术。 采用迭代的实验方法代替。
- 每个微服务架构都是独一无二的; 选定的技术应与系统的需求保持一致。
- 请记住，太多不同的技术使招聘更加复杂。
结论
在切换到微服务架构时，存在许多挑战。
在开始将系统转换为微服务之前，请确保有真正的理由说明为什么要这样做。了解优势和劣势可能会有很大帮助。您不必遵循最新的炒作，而是首先考虑系统的独特功能，而只是改变最容易受到伤害的系统部分。不建议从头开始使用微服务架构，因为很难明确定义微服务的边界。
如果您决定切换到微服务，请采用增量方法并取出系统中一个非常关键的小部分，以了解其工作原理。这也是获得组织支持以创建更多微服务的好方法。
没有一种最佳方法可以为微服务选择完美的技术。每项与技术相关的决策都会受到您团队当前知识以及公司未来招聘计划的影响。在某些情况下，为微服务选择技术更多是招聘决策，而且取决于您希望在未来构建哪种类型的开发人员团队。
