10位技术领袖告诉你趟过的微服务那些坑和最佳实践

小数导读: 切换到微服务架构似乎很容易,但技术领导者往往低估了项目的复杂性,并犯下灾难性的错误。此文对来自以色列和美国等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