你应该更谨慎的采用微服务

标签: 微服务 | 发表时间:2020-04-12 23:42 | 作者:grace_shi
出处:http://weekly.dockone.io

(微服务)不就是写一堆小的程序么?

某一天,你正在寻找一种新的方式来重构整个代码库。您考虑过使用一种新的语言,或者在另一个云服务商上进行部署,又或者是使用一种更好的编程模式。之后您找到了它 - 微服务。突然,你发现你可以同时实现这三种方式。

对于初学者来说,“微服务”是一种架构模式,其中,一个应用程序是由多个松散耦合的服务组成,这些服务都可以独立部署。

依你所见,这个架构可以解决你所有的麻烦:

  • 设计新产品或者新功能将变得十分容易,你可以创建一个代码库,这个代码库专门用来解决特定的问题。这简直是开发模块化的最理想化实现。

  • 具有大量依赖关系的大型应用程序可以进行分解,从而可以更快,更轻松地运行测试套件以及梳理清楚每个域的逻辑

  • 你会感觉这就像Google一样

  • 微服务使用RESTful API或gRPC之类的工具处理API调用。如果您的单页应用(SPA, Single Page Application)与后台是通过类似方式进行通信的,那么微服务架构将发挥更大的作用。

  • 您会感觉就像支付宝(可以使用各种银行卡进行消费)。

  • 您可以在每种服务中使用不同的语言和技术栈,以便“使用最佳工具集来完成任务”。


那么可能会出现什么问题呢?

下面我将给出三个论点,为什么微服务不是一件容易的事。我确实认为它们对于构建大型和可扩展的系统很有用,但是必须认识到采用它们的时候会产生的操作和技术上的债务。

标准化问题

一般开始编写微服务的方式就是采用标准的应用程序框架,并使用这个框架来编写一些实用的服务。使用Django,Rails,.Net Core和Spring Boot这些技术的团队,并且肯定不会将其视为反模式。您可能需要针对诸如推送通知,图像大小调整以及域逻辑隔离位之类的功能的服务。

但是问题就出在,有一些元素是需要在多个代码库中标准化的。例如:
  • 指标
  • 管理云相关的逻辑,例如使用对象村相互或者密匙管理服务
  • 密码管理以及任何对环境变量的使用。
  • API 约定的Schema定义。
  • 服务端逻辑,例如验证,授权,日志记录以及限制.
  • 抽象化数据库


您可以通过创建共享库或者一次次重复实现来实现这些逻辑的标准化,但是这存在两个问题:
1. 如果对共享库进行更改,你所有的服务不会自动更新共享库的版本。这使得一些安全性的修复可能变的很难覆盖到所有的服务。这也使得大家不愿意去优化这些共享库。
2. 采用新技术或者新语言,将会导致在开始之前,你便需要为新技术创建或者维护新的库

本·克里斯滕森(Ben Christensen)的演讲中也提出了类似的论据,他在演讲中讨论了创建“分布式整体”的风险。这是一个不公开的视频,已链接到Monzo的博客文章。

我认为Monzo的博客也提示了一个解决思路。他们正在考虑为所有的“共享基础设施”例如数据库和消息队列构建服务。这使得所有跨领域服务依赖关系都可以用API来解决而不是使用共享代码库。这的确很整洁,但是显然需要很多工作。

Devops问题

不需要多说,当你需要部署一大堆服务的时候,持续集成和部署将会令人头痛,这里有两个例子:
  • 你需要进行复杂的端到端测试来确保所有的服务服从API约定。但是,如果你有一个服务,比如一个邮件发送器,当众多服务被测试时,需要模拟出特定的测试条件,你该怎么办?你是替换掉整个服务,还是在服务本身有一些逻辑来识别它是否在端到端的测试场景?
  • 服务越多,你将花费更多的时间来配置你的部署。例如,如果你有一个架构,每个服务都有自己的数据库,那么可能需要为每个服务配置不同的密码。这就加大了生产中的配置错误的可能性,也增加了自动化创建新环境的难度。


对于以上问题,一个微服务工程师可能会配置一大堆 .yaml文件,或者使用一个容器编排框架,例如Kubernetes,但是我不会使用Kubernetes,除非我能请一个专门的工程师来管理Kubernetes。
  • 网络非常复杂。分布式系统预设了服务之间的联网,但要安全、可靠地做到这一点,需要花费一些心思。如果出现服务超时怎么办?我们要重定向失败的HTTP请求吗?我们需要对流量进行加密吗?
  • 设置一个编排框架`并不容易。云提供商仍然会要求你来考虑需要配置什么硬件,这往往会让人感觉与市场上的无服务器(serverless)解决方案相去甚远。在某些情况下,对于早期初创企业, 如果寻求少量部署配置,无服务器架构可能是一个更好的选择。
  • 定义服务,尽管我很喜欢manifest文件来声明方式,但是这并不简单。我们需要定义资源限制以及扩展策略,这些都不能很明显的知道,需要在生产版发布之前,进行实验,才能很好的去定义这些。


这些问题都不是不可克服的。事实上,我很期待Knative产品(如Google Cloud的Cloud Run)能将无服务器范式的元素带到更传统的微服务部署中。同样,CI/CD的问题也可以由一个聪明开发团队来解决。

但是,同样,这并不容易,需要合理规划。

开发问题

如果采用微服务架构,那么在写代码的思路上做出重大改变。

下面是一些例子:
  • 微服务通常预设每个服务都应该被编写成可以通过编排框架来自动进行水平扩展。这可能需要那些来自单例应用的人考虑一些问题,比如管理共享资源连接池,以及共享内存内信息等问题。
  • 像Kubernetes这样的编排框架也可能会频繁地关闭或启动服务,并期望任何服务都能处理好。尽管如此,优雅的关机并不容易,而且--根据你的技术栈--可能需要思考如何记录日志和确保完成任何正在进行的计算。
  • 最后,许多微服务架构将利用消息队列来构建的基于事件的架构。有些消息队列技术会保证至少一次交付,这就要求处理程序在消息重复的情况下,必须是幂等性的。在一个大型系统中,实现、测试和维护方面会相当头疼。


公平地说,以上三点可能是大多数架构中部署时需要考虑的事情。然而,微服务可能意味着你的每个服务都需要无数次面对这些问题。

结论

微服务有其适用的时机和地方,但其进入门槛比许多人认为的要高得多。这种架构是可以逐步采用的,但是在设计和规划阶段需要付出大量的努力和专业知识就才能开始采用。

-----

【原文链接】 Why Microservices Should Scare You More
译者介绍 Grace,程序员,研究生毕业于SUNY at Stony Brook,目前供职于Linktime Cloud Company,对大数据技术以及数据可视化技术感兴趣。

相关 [微服务] 推荐:

初识微服务

- - ITeye博客
微服务架构越来越火,有必要学习一下. 软件开发过程中碰到什么问题. 一个简单的应用会随着时间推移逐渐变大. 在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码. 几年后,这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦. 敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务性能模式

- - 互联网 - ITeye博客
前言:基于微服务系统越来越普遍. 下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们. 背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从Excel到微服务

- - 乱象,印迹
Excel很老,Excel很土,Excel一点也不sexy;微服务新,微服务很潮门,微服务很高大上. 那么,Excel和微服务有什么关系. 上个月看了篇文章,The Unbunlding of Excel. 作者认为,对于初创公司(尤其是非“纯IT”初创公司)来说,Excel几乎包办各种工作. 想做轻量级的CRM,可用Excel.

微服务框架Spring Cloud介绍 Part2: Spring Cloud与微服务

- - skaka的博客
之前介绍过 微服务的概念与Finagle框架, 这个系列介绍Spring Cloud.. Spring Cloud还是一个相对较新的框架, 今年(2016)才推出1.0的release版本. 虽然Spring Cloud时间最短, 但是相比我之前用过的Dubbo和Finagle, Spring Cloud提供的功能最齐全..

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

(译)面向性能的微服务

- - mindwind
从性能响应延迟的角度解读微服务带来的影响,并提出了几个保证服务低延迟的建议. 微服务是目前的一个热门词汇. 它是原创的还是基于最佳实践产生的. 虽然在实施微服务的过程中有一些缺点,但这些缺点能被克服么. 一旦你组装好了一个大系统,那么几乎不可能监测到系统的最大延迟来自哪里. 你可以监测到平均的延迟和吞吐量,但为了达到稳定的延迟,需要去分析系统的关键部分.