首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

微服务带来的心理阴影

架构的演进基本上是按照最早的单体服务架构开始,将所有的功能模块(service)打包到一起。

再到后来的微服务架构,就是将复杂臃肿的单体应用进行细粒度的服务拆分,每个微服务可以交给小的团队进行开发和维护,拆分出来的服务各自独立打包部署。

那么经历过整个架构演进过程的技术专家们,他们在研发工作过程中,有哪些明显的感受,对于解决技术问题有哪些更好的经验?对未来的架构趋势有哪些预判?

在此前的一次ArchSummit全球架构师峰会上,我就邀请了业界几位技术老师:赵宇辰(听云)、雷卷(阿里)、李智慧(同程艺龙)、张宏伟(美菜网)、冯湧(Shopee),一起探讨了这个问题,总结来说,单体架构不是那么苦,微服务架构也不那么香,中台架构也不甜。(内容太多,分为上下篇)

微服务之——初体验

首先,能经历过这三个过程的技术人,一般年纪都比较大,所以他们的经验值得你细品。

雷卷老师一直在阿里硅谷 Office 做云原生和 Reactive 研究。2006年加入阿里的时候,当时阿里是巨型的单体应用(买家、卖家、CRM),慢慢的基于 Spring boot,Spring Cloud 框架调整到微服务架构。现在往中台方向发展。雷卷老师认为这样的道理是正确的,需要把同类型的应用进行收敛,提升扩展能力,形成中台能力。

李智慧老师2008年的时候也在阿里,当时做分布式服务,Dubbo 就是当时所在的团队做出来的。李智慧老师当时主要做架构支持,遇到过很多Java War打包的伤心历史,所以现在会扪心自问:我们究竟想要通过微服务得到什么?服务拆分确实有它的好处,例如分布式服务好管理,开发编译更方便,运维工作更简单等等。但紧随其后需要考虑服务能不能有更大的用途?是否可以复用到其他业务?拆分容易,复用可没那么简单。

做微服务能够解决技术性问题,但是做中台其实解决的不只是技术的问题,那么其实难度和复杂度会更大,挑战也会很多。

美菜网的张宏伟老师说,他们现在的中台团队主要的学习对象就是阿里,微服务框架也是用Dubbo。美菜网从单体应用到微服务,然后到中台,为什么要做这样的升级?

美菜网 1.0 版本就是为了验证商业模式是否可行,业务是否能正常运转。2.0 版本是在研发人员规模扩大之后,当时因为业务增多,导致数据不一致,也直接影响测试结果。结果只能做服务的拆分,向为微服务发展。在随后的4年里,微服务体系支撑了上百个城市,每天几十万的订单量业务。

技术上的问题解决了,业务上的问题又来了——分销类业务,还有其他各种各样的创新业务,但各业务本质上都是类似的,很多相同部门在做相同的事情,效率还很低。所以最终找到的解决方法就是中台。上线半个月发现效果很不错。中台一方面能解决技术上的问题,另一方面也能解决业务上的问题,能让业务快速裂变。

王启军老师来自于华为公司架构部,主要是做云原生和微服务架构推广。做过消费者云,还有 PaaS 框架、微服务框架、多云管理系统 Manage One 等工作,都涉及到微服务和中台的概念。但是理论上来说,团队在做项目的时候,并没有刻意追求微服务概念,主要是为了解决一些问题,可能刚开始的时候在做服务拆分,后来研发团队太大了,自然而然要拆分,为了解决效率低下的问题。

拆分之后又讲究垂直拆分,如果开始的时候做很多水平拆分,可能会导致调用关系很复杂,性能很低。垂直拆分之后,很多地方组合起来不太方便,导致 API Gateway 特别臃肿,那只能把一些业务分层,也就变成了我们现在所说的中台。

冯湧老师目前在新加坡电商Shopee(虾皮),主要做风控,反欺诈工作。之前任职于苏宁易购和美团金服。在Shopee工作阶段发现东南亚每个国家的电商有自己的特色,例如语言多样化,文化多样性,购物习惯不同,不同的支付合规要求,各个国家独立的政策,不同的宗教等等,一个功能要面临7个国家分支。

所以 Shopee 更需要中台/平台能力,对灵活性要求更高,而微服务架构更能满足商业复杂度需求,服务治理、服务可用性,服务稳定性以及灵活性更有保障。

什么时候拆?怎么拆?拆多细?

实际工作中,也听到很多技术人的吐槽,什么情况下单体要拆微服务,有没有一步到位的办法,传统的应用到底怎么拆?拆多细?如何去衡量?

赵宇辰老师就提到,类似于银行、军工传统这些客户,帮助他们将服务部署到本地,但是客户没有很好的机器,硬件配置较低。另外,ToB客户在部署应用的时候,遇到问题不知道如何去解决,这样比较头疼。

针对这样的问题,雷卷老师说,如果只是做ERP、CRM或者OA的,就是一个单机的应用,部署到客户环境,客户每天的访问量不大,单机又没有成为瓶颈;或者对于小型创业公司,刚开始做第一个应用,那就没必要做微服务。

另外从技术层面上讲,比如用 HBase 在设计的时候,对事务一致性要求极致,若拆成微服务,就会有网络延迟之类的问题。关于部署问题,如果客户还没有做容器化、虚拟化,通常也不建议采用微服务。不过,现在 K8s 比较流行,随着技术的变革,之前认为不可能的事情就会变得有可能。但一些典型的场景,比如多租户情况下对流量、扩容有强烈要求,那肯定需要采用微服务架构。

至于拆分到多小,按什么力度来拆分?有很多方法论值得参考,例如 DDD 方法论,它会告诉你如何识别业务系统,如何拆分微服务,怎样做通讯等等。

李智慧说这是一个挺沉重的话题,因为李老师之前给一些企业提供咨询服务,关于微服务架构,有一些痛苦的经历。

什么时候应该微服务?李智慧老师的个人经验是,如果要做一个创业公司,做一个新的应用,建议刚开始的时候就设计微服务架构。因为服务本来就是隔离的,可以强制你去独立思考业务模块,逼迫你每天去思考:服务之间的关系是什么?应用之间如何用服务进行组合?这样的思考有助于架构设计,模块之间的关系会更清晰。

现在的单体应用要不要开始去做微服务?该怎么做?这属于特殊情况。但是直白点讲,微服务就是接口进行远程调用的问题。微服务的建立基础是要有一些独立的模块,这些模块便于在微服务过程中进行远程部署。而这些模块本身应该是独立的,逻辑关系和依赖关系应该是清晰的。有的应用可以是微服务调用,有的应用还是本地调用。

比较痛苦的经历是,给企业做咨询期间,他们认为远程调用就是实现了微服务,但是模块之间边界,调用依赖关系没整理清楚,互相之间不断的重新循环,服务A依赖B,B依赖C,C又依赖A。最后导致任何一个需求变更,整个系统全垮。需求一上线出Bug,然后两三周进行修复。这个痛苦过程简直不愿再去回想。所以说,横向的分层关系与纵向的垂直关系一定要搞清晰。

张宏伟也很赞同互联网服务最好是从微服务开始做。微服务其实是偏工程型的代码系统,也代表着协作模式上的变化。所以建议根据团队规模和后续发展规划来拆分微服务,不要拆的太零散。

王启军老师强调了一点,不要只是拆分服务,只是把服务拆开其实没有什么意义。还要考虑相关配套东西,比如说部署的时候要用到 Kubernetes、容器、持续交付等等,这些配套服务也要考虑进去。

冯湧老师关注微服务中的成本问题,例如业务试错成本,先验证一下商业模式,在这种情况下,把一个服务拆的太细并不是明智的选择。其次是要考虑建设成本。微服务可以理解为一艘航空母舰,它周边是有很多舰艇组成战斗群。它需要很多的能力支撑,包括服务治理、运维上线、质量保障等等。如果现在还是小团队,小业务,那就安心做业务吧。

微服务实践中踩过实实在在的坑

雷卷老师工作20多年,他说踩坑经历肯定是有的。从原来单一进程改为跨进程分布式调用就会出现很多问题,比如 Transaction事务没法控制,之前设计的API 会失效。

这里雷卷老师举了个例子,之前淘宝店铺里卖家都会装修店铺,让店铺变得很好看,装修了十几个页面,在六一儿童节、三八妇女节、双十一的时候一次性发布,这些大促时间比较长,有可能在某一个环节就会出现问题。比如远程调 API 的时候出现一次失败,且没有分布式的事务来控制,所以就比较麻烦。

所以在拆成微服务之后,远程网络确实是一个很大的问题,同时对接口设计也有很大的挑战。因为在一些关键性事务上,不能按照 Rest API 来做设计,要提供更面向业务性、原则性的 API 暴露给外部调用。解决的办法也有,把 API 各种页面状态更改之后归拢形成一个原子化,增加一个幂等性判断,以确保最终的事务一致性。

李智慧老师回忆起当初看到微服务概念提出者 Martin Fowler 撰写的《企业应用架构模式》这本书的时候,惊为天书,佩服他对软件理解的透彻程度,所以当时对 Martin Fowler 非常崇拜。而且很清晰的记得书中讲到的分布式第一定律,那就是“不要使用分布式“。但事后来工作中要解决业务问题,也看到使用分布式服务能带来更多好处,所以最后也积极参与了进去。

李老师这么多年的实践,会促使他去反思:投身微服务之前要问问目标是什么,当前的问题究竟是什么?如果没想清楚,建议不要盲从,适合阿里的技术,不一定适合你。

另外,不能用看待 Kafka、Redis、RocketMQ 等技术的眼光来看待微服务,它和业务密切相关联,但它不是一个技术问题。

虽然微服务听起来越微越好,但李智慧老师认为,“微”只是一个目标和愿景,建议刚开始做的时候先往大范围拆,业务独立出来,其他服务或者核心逻辑拆成一个大服务,看起来像没拆,但可以根据这个思路去验证技术,验证完之后再往往小拆,循序渐进,会更轻松,更顺利,即使踩坑了,也知道在哪踩了坑。

李老师经历了一个代价非常大的循环依赖项目,不断的投入优秀的人力进去填坑,耗尽心力,精疲力竭。项目结束后,这些技术人对公司、对项目、甚至对技术产生了心理阴影,最后选择辞职。

所以李老师建议大家,选择微服务之前谨慎谨慎再谨慎。

冯湧老师更关注服务治理,当公司越来越大的时候,服务内容的治理,比服务本身健康度治理更重要。

例如研发团队上千人的公司,每个团队负责一个业务方向,且都以微服务的方式来进行相关的系统能力建设。一旦遇到公司级促销活动,对于类似于“对账、营销”等底层技术能力的时候,会很疑惑这么多五花八门的技术,到底该用哪个?所以,冯湧老师建议,在未来做规划架构、架构治理工作的人,要更加关注技术上如何合并,哪些适合微服务体系,哪些适合底层基础建设体系,防患于未然。同时在做服务拆分的时候,服务定义要明确:业务职责、业务场景,避免给服务治理风暴留下潜在风险。

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/wNFKtQc9VjBaEugemrjg
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券