小数导读：
切换到微服务架构似乎很容易，但技术领导者往往低估了项目的复杂性，并犯下灾难性的错误。此文对来自以色列和美国等5个国家的技术领袖进行了13次采访。这篇文章很长，内容包括如下一些方面：
•微服务是什么
• 微服务架构优劣势分析
• 微服务面临的挑战和应对解决方案
• 微服务落地要避开的坑
• 来自技术领导型企业的微服务架构最佳实践
• 如何选择微服务当中的技术栈？
• 实用的技术建议
为什么转向微服务？
企业容易犯的最大错误是在没有明确目标的情况下，转向微服务架构。需要了解并有真正的理由表明为什么要这样做。
“人们盲目进入很多领域：Docker很酷，微服务很伟大！但它可能不适合你的体系构建，你需要了解为什么要这么做。” - 来自Steven McCord，ICX Media（一家企业营销视频制作众包平台 ）创始人兼CTO。
如果你的系统工作正常，那有什么动力去改变它？
如果只是因为微服务被炒作，这并不意味着你需要跳入潮流。它不一定是企业软件的最佳技术选择。
“确定原因至关重要。”这是David Dawson，Steven McCord和Avi Cavale 所强调的。
“当客户要求我实施微服务时，我会问的第一个问题是，为什么？我正在寻找的答案是，“希望更快地改变系统”和“希望利用云技术”。微服务其实比建立单一的系统更昂贵和困难。微服务在数据模型中引入网络，可以随时进行任意分割，但也可能伴随数据丢失，让企业暴露在分布式计算的恐惧之中。“ - 系统架构师 David Dawson说道。
明确定义一个微服务
“我不一定选择微服务。我倾向中型服务，所以不是从单体架构转到上百种的微服务，而是与工程团队和业务保持一致的更大的服务。” - 来自Daniel Ben-Zvi , SimilarWeb（网站和应用追踪分析公司） 研发副总裁。
>>>>如何做？一个围观案例研究
“我们通过查看哪些代码（如果更改的话）最终确定了指数测试案例，从而确定了一个微服务。我们的目标是减少对每次改变的测试次数。如果这是你的目标，那么微服务的定义就和”计费就是一个微服务”没有什么不同。”Shippable 联合创始人兼CEO Avi Cavale 说道。
微服务架构优劣势分析
>>>>微服务显著优势
可扩展性：分析小块的应用，看每块的要求，每部分可以分别伸缩应用程序的不同部分。
“另外一个好处是，可以在任何虚拟机之外扩展容器。容器可以放置在任何形式的配置中，应用程序具有完全的可移植性。“ - ICX Media 创始人兼CTO Steven McCord说道。
更简单的可维护性：不同的团队以不同方式独立处理不同的组件。
独立部署和配置：部署和配置每个服务时，不会影响其他服务。多个团队可以将多个结果投放到生产中，不会彼此干扰。
问题隔离：更容易隔离和监测问题。
易于招聘：寻找开发人员或第三方供应商时，只需培训他们系统的一部分。
清晰的责任：一个团队负责特定的微服务。
深厚的知识：团队从内到外了解相关知识。
多种编程语言：可以使用不同的编程语言，这取决于微服务的目的。
更易于监督和理解：将庞大的代码分割成更小的项目，利于团队更好地理解。
更容易开放组件：当边界和接口被明确定义时，向新的业务单元开放组件或现有功能更容易。
>>>>微服务劣势
部署和互操作性：这是首要问题。
编程语言太多：会限制代码的可重用性以及可维护性，并且维护更加复杂。
组件一起工作：要确保服务是以一种协同工作的方式组成。只考虑改变单一的端点，会打破旧版本的其他依赖服务。
与单体系统相比，更难以对整个系统进行集成测试。
架构必须从一开始就深思熟虑：如果服务之间的凝聚力过大，也会失去大部分优势。
加大通信力度：在服务之间的通信方面，需要进行投入。服务的通信之间容易发生故障。
难以监控整个系统：大量组件对监控来说，是噩梦。
花时间学习：使用微服务需要学习，这需要时间。
复杂性：越来越多的微服务使整个系统更加复杂，难以监控。
“所有这些东西都散在周围。如果没有很好的工程流程，企业最终获得一大堆东西，然而根本不会使用。” - Shippable联合创始人兼CEO Avi Cavale说道。
“在基于微服务的平台上调试生产问题是完全不同的操作。如果没有相应的监测，记录和跟踪设施，系统的复杂性会显著增加。这就像迷宫一样。工程实践和标准化至关重要。” - SimilarWeb研发副总裁 Daniel Ben-Zvi 说道。
“记录到一个地方有挑战性。Loggly，Splunk或Heroku等第三方日志聚合服务是非常好的解决方案，但价格非常高。根据我的经验，遥测特别集中的日志是最大的难题。必须考虑每个服务的详细程度。否则，企业可能要花费50-60％的成本进行记录。”-来自微软公司SRE工程师 Sonu Kumar。
微服务面临的挑战和解决方案
当转向微服务时，如下这些是技术领导者和开发团队面临的最大挑战。
• 挑战1：一次切换所有系统
• 挑战2：拆分系统
• 挑战3：组织认同
• 挑战4：团队
>>>>
挑战1：一次切换所有系统
“从单体架构切换到微服务架构不是一次就可以完成的。如果企业有单体服务器，那么其周围可能被存储库，部署任务，监控和其他许多事情包围。一起更改并不容易。” - AdRoll软件工程师Brujo Benavides说道。
“如果一个公司从未有任何微服务经验，即使是新建，也会比想象的更难。” - LogMeIn DevOps工程师 Viktor Tusa 说道。
white_check_mark：可能的解决方案
“那时候我们做的是保留单体服务器，但是任何新的服务都是通过微服务来开发的。”（Brujo Benavides）
>>>>挑战2：拆分系统
“如果组件和服务聚集在一起，隔离起来相当具有挑战性。（Robert Aistleitner）。需要定义各个部分之间的交互和流程。如果没有很好的定义，系统会产生更多问题。”- StyleSage高级开发人员 Jose Alvarez 表示。
“将系统拆分成微服务有许多不同的规则，没有特定的模式，没人会告诉你，如何在应用程序中使用它。而且，没有两个相同的微服务”。 - Recart 首席架构师大卫·帕普说道。
white_check_mark：可能的解决方案
“把单体系统分解成微服务的唯一方法，是首先检查单体系统，看看它最“痛”在哪里。将这些部分拿出来并转化成微服务“。 - Emarsys工程副总裁Andras Fincza表示。
监控所有部分是如何工作的以及他们在做什么。监控过程中，可以很容易地发现和解决问题。(Jose Alvarez)
模块by模块渐进地分离单片系统是最好的方法。想一次做所有事情，一定会失败的。
监控工具提示：
• New Relic
• Datadog
• Influxdb
• Grafana
>>>>挑战3：组织的支持
“获得组织认同可能是最难的部分。” - 来自 Steven McCord ，ICX Media创始人兼CTO。
这不是一个技术决定。需要清楚说明微服务架构的好处，从而说服企业重新分配资源。在企业接受变革之前，这是一个漫长而乏味的过程，组织规模越大，决策的时间越长。
white_check_mark：可能的解决方案
说服组织改用微服务的最佳方式，是将非核心部分转换为微服务。通过这种方式，来展示微服务的优势。
>>>>挑战4：团队
“团队本身面临着最大的挑战，它需要不同的思考。” “开发人员必须花费更多时间来了解什么是端到端场景。他们需要熟悉这些技术，需要转换思维方式。”
“对于一个在端到端测试的世界中工作的人来说，突然把它分解成小块，是不舒服的，这更多是文化上的变化。”-Shippable 联合创始人兼CEO Avi Cavale说道。
white_check_mark：可能的解决方案
从非常小的可以真正受益的方面开始，并选择应用程序的非关键部分。获得一个小团队的支持，并将这部分转换为微服务。一方面来证明微服务的优势，另一方面逐步向企业扩展（Avi Cavale）。
微服务落地要避开的坑
“避免同时将整个系统切换到微服务。” - Emarsys工程副总裁 Andras Fincza 说道。
“你能犯的最大的错误就是，没有创建一个微服务架构变化可能带来的影响概览。在实际开始实施新方法之前，必须包括大量移动组件。“ - Usersnap工程副总裁Robert Aistleitner说道。
“单体架构很容易改变内部接口。只需重构代码，然后运行测试。使用微服务，API必须可靠，你不一定知道你所有的客户。如果没有API的话，会给未来带来许多麻烦。此外，确保有分布式跟踪系统。”-来自 Daniel Ben-Zvi ，Similar Web研发副总裁。
“不要在没有搞清楚平台和依赖关系的情况下，尝试切换到微服务。此外，也要避免认为微服务都不错，因为每一个微服务可以用不同的语言来编写是一个不好的做法。” - 来自Viktor Tusa ，LogMeIn DevOps工程师 。
“处理数据至关重要。搞砸数据非常容易，但是很难恢复。数据迁移需要更多步骤。” - Emarsys工程副总裁Andras Fincza表示。
“在微服务之间共享数据是一个很大的禁忌。如果两个服务操纵相同的数据，将遇到一致性问题，并消除所有权。“ - Daniel Ben-Zvi＆Varun Villait二者共同认为。
“把应用程序分解成太多太小的东西，或者强迫把系统转变成微服务，这不应该是微服务 - 仅仅是炒作”。- 来自 Doctusoft首席开发Csaba Kassai 的观点。
来自技术领导型企业的微服务架构最佳实践
创建微服务之间的隔离，可以根据需要快速更改它们。这通常需要在几个层面进行隔离：
运行时流程：这是最明显的，也是普遍采用的过程。以前只有一个流程，而现在有很多。这里的主要成本是采用某种形式的分布式计算，这很难做到。会导致采用容器化，事件架构，各种http管理方法，服务网格和断路器。
团队/文化：分离团队，给予自主权，意味着划分人与人之间的沟通。这往往会导致知识孤岛和工作重叠（解决选择性与资源效率的选择）。
数据：采用像微服务这样的分布式计算最大的影响是它影响企业的数据。以某种形式对数据进行划分，需要在系统级别重新整合，以给出“一个系统”的印象。这在伸缩方面有潜在好处，但也需要相比简单的单一数据架构方法的更多想法。（来自David Dawson）
如何选择微服务当中的技术栈？
这是不同意见开始碰撞的地方...
一方面，人们认为使用什么技术和编程语言并不重要。
“几乎所有的问题都可以用任何技术解决。人们花费太多时间寻找正确的技术，如果以迭代的方式来做，你就有时间思考，并看到它的实际应用。错误的决策也可以得到缓解。” - Andras Fincza ，Emarsys 工程副总裁表示。
“大多数现代语言（Python，Java，C＃，Node / JavaScript）同样快速且可扩展。从这个角度来看，语言无关紧要。每种语言都有其优点和缺点。大部分时间，语言选择是根据个人的喜好，而不是技术参数。” -Andras Fincza ，LogMeIn DevOps 工程师说道。
花费大量的时间来选择最好的技术是不值得的，因为差异很小。
“选择技术的重要性被高估了。如果运行成本很重要，那么就可以接受，对我们来说没那么重要。” - Andras Fincza ，Emarsys 工程副总裁。
“如果是新建项目，选择程序员最了解的语言。如果不是，选择客户端上最佳覆盖业务系统的语言。” -Viktor Tusa ， LogMeIn DevOps 工程师 。
“微服务的好处在于它被封装在一个微服务中，只需要给外部的接口来谈论这件事。只要有一个界面就够了。“ -Steven McCord ， ICX Media创始人兼CTO 。
选择合适的技术不仅仅是技术问题，也是一个决策。如果选择一种具有10种不同编程语言的微服务架构，要确保团队能够处理该问题。
“我不推荐混合太多的编程语言，因为招聘会变得更加困难。而且，程序员的上下文切换会减慢开发速度。“ - Robert Aistleitner ， Usersnap工程副总裁。
“必须有意识地选择想要建立的开发团队类型。如果想使用许多不同的编程语言，需要建立一个能够使用和学习不同编程语言的动态团队。“ - Steven McCord ， ICX Media创始人兼CTO 。
实用的技术建议
“我强烈建议在Google云端平台中使用管理服务，如App Engine。这将肩负很大的负担。此外，选择语言/技术时/框架时，选择合适的针对特定微服务的使用情况是重要的，不要因为熟悉它，而强迫选它。” - Csaba Kassai ，Doctusoft 首席开发。
>>>>以下来自Brujo Benavides：
一些技术领导者乐于推荐一些技术，这些技术可以很好地适用于服务特定角色的微服务。在选择微服务技术时，建议考虑：
• 可维护性
• 容错
• 可扩展性
• 架构成本
• 易于部署
Brujo团队的一些微服务框架/技术示例：
• Scrapy for web crawling
• Celery + RabbitMQ用于微服务通信
• NLTK + Tensorflow（以及其他一些）用于机器学习部分
• AWS服务
如何选择合适的技术/语言？
在为微服务选择编程语言/技术时，需要考虑很多事情。
其中最重要的就是看你的开发人员具备哪些能力，以及语言/技术背后有多大的支持（工具，社区......）。根据我的经验，公司倾向于根据其开发人员的能力选择一种编程语言。“ - Csaba Kassai ，Doctusoft首席开发人员。
“使用技术背后有很多支持（资源和活跃的社区）。我推荐Ruby和JavaScript，可以得到很多支持，如果出问题，很多人都可以提供帮助。只要确定有很多人使用它，选择语言不应该是问题。如果团队不具备这些知识，可以依靠外部资源。“ - Varun Villait，Industry CEO。
“另一个因素可能是图书馆可以用来加速项目的语言。你理想的语言的某些东西可能图书馆没有，不得不自己发明，这是另外的时间流失。容错和可扩展性也是重要因素。如果从现在开始的几个月内，你不得不重新编写一些东西，因为最初的选择无法扩展，那不如放弃。这一切都归结到一个特定的团队情况，他们愿意进行投入。” – Greg Neiheisel , Astronomer联合创始人兼 CTO 。
Emarsys就是这样看待这个过程的：
在Emarsys，如果他们想应用一种新的编程语言，开发人员需要提供真实的，合乎逻辑的理由，并咨询主要开发人员。团队聚集在一起讨论技术的优缺点。
他们总是用不同的技术创造一个尖峰解决方案。这可以让他们试验一个给定技术的边界，看看它是否可以应用于给定的微服务。这对于发现技术的局限性是完美的。
“建议使用您的团队已经熟悉的语言。这样，他们可以工作更舒适，进展较快。” –来自 Andras Fincza，Emarsys 公司工程副总裁 。
>>>>这是他们在SimilarWeb上所做的：
作为一家大数据和分析公司，我们面临着非常大的挑战，这增加了选择错误技术的风险和影响。单线程框架（如NodeJS）虽然适用于网络绑定服务，但在处理实时密集型数据处理时不会扩展。
工程师通过平衡战术和战略需求，同时考虑技术和组织的约束条件，来确定使用哪种技术。企业正处于快速成长阶段吗？服务是否需要处理大量数据？是否希望将新技术添加到堆栈中，是因为相信它的生态系统，还是使用我们已经掌握的现有技术？想要试验吗？能找到对此充满激情的工程师吗？是否愿意长期致力于这项技术？技术的生态系统是一个主要因素。我们希望与开源社区合作，使用和贡献现有的框架，而不是重新发明。
定义明确的指导方针甚至是清单可以帮助促进健康的决策过程，缩小可能的技术选择范围，从而选择最适合的团队和产品方案。
>>>>David Dawson提出的选择建议：
1.从数据架构的角度来看，需要一些可以轻松地将数据同步到服务之间的网络，并保持一致的可用状态。有很多种方法，这正是微服务部署中所需要的。可以观察实现这些模式的各种框架和技术。
2.一旦确定了模式和方法，就可以使用可用的资源来分析。如果已经决定采用大量反应式编程的数据流方法，并且拥有Java开发人员，那么选择Spring，Spring Cloud Data Flow和Kafka并且部署到某种形式的Cloud Foundry上（如果可以得到它！）。
如果需要大量更重的数据转换，请带上Spark或Kafka Streams 来解决这个问题。如果有JavaScript 开发人员，那么这个问题是没有道理的。相反，你会希望在JS运行时（clojurescript等）采用一些功能语言，再次使用一些类似的反应式集成技术（比如Kafka），并从那里采取。
关键要点：
• 不要强调完美的技术，采取迭代的实验方法。
• 每个微服务架构都是独一无二的; 所选择的技术要与系统需求保持一致。
• 太多不同的技术使招聘更加复杂。
结论：
切换到微服务架构时，有很多挑战。在将系统转换为微服务之前，请确定要实现这一目的的真实原因。优点和缺点的分析会是一个很大的帮助。首先考虑系统的特性，而并非仅仅改变那些伤害最大的系统部分。不建议从头开始使用微服务架构，因为从一开始就明确界定微服务的边界是困难的。
如果决定切换到微服务，请采取渐进式方法，并从系统中取出非关键的一小部分，来了解它是如何工作的。这也是获得更多微服务的好办法。
对微服务来说，没有最好的方式可以选择完美的技术。每个与技术有关的决定都受到团队当前知识的影响，也受到公司未来招聘计划的影响。在某些情况下，选择微服务技术更多的是一个招聘决定，这取决于将来要建立一个什么样的开发团队。
为了缩窄可能的技术范围，来自Emarsys 的Andras Fincza，SimilarWeb的 Daniel BenZvi和David Dawson提供的经验值得借鉴。
文章来源：
https://www.tuicool.com/articles/zaMnIz3
网友评论