微服务架构是从单体架构演化而来的。所谓单体架构,指的就是整个互联网系统所有代码打包在一个程序中,部署在一个集群上,一个单体应用构成整个系统。而微服务架构则是将这个大的应用里面的一些模块拆分出来,这些模块独立部署在一些相对较小的服务器集群上,而应用通过远程调用的方式依赖这些独立部署的模块,完成业务处理。这些被独立部署的模块就被称为微服务,而这样的应用架构也被称为微服务架构。
应该说,模块化、低耦合一直以来都是软件设计追求的目标,独立部署的微服务使模块之间的依赖关系更加清晰,也更加隔离,使系统易于开发、维护,代表了正确的技术方向。但是在实践中,有时候却会出现这样的情况:用了微服务,系统反而变得更加难以开发、维护。技术团队痛苦不堪,觉得是微服务的锅,主张放弃微服务,退回到单体架构。
那么,究竟该不该上微服务?微服务是灵丹还是毒药?
单体架构的困难和挑战
(1)编译、部署困难
一个应用系统一个 war 包,这个 war 包可能有几个 G 大。对于开发工程师来说,开发编译和部署都是非常困难的,当时我用自己的电脑编译这个 war 包,大约需要半个多小时。工程师在开发的过程中,即使只改了庞大系统中的一行代码,也必须重新打包完整的系统,才能做开发测试。这样的单体系统对于开发部署和测试都是非常困难的,有时候甚至一天都写不了几行代码。
(2)代码分支管理困难
因为单体应用非常庞大,所以代码模块也是由多个团队共同维护的。但最后还是要编译成一个单体应用,统一发布。这就要求把各个团队的代码 merge 在一起,这个过程很容易发生代码冲突。而 merge 的时候又是应用要发布的时候,发布过程本来就复杂,再加上代码 merge 带来的问题,各种情况纠缠在一起,极易出错。所以,在单体应用时代每一次应用发布,都需要搞到深更半夜。
(3)数据库连接耗尽
对于一个巨型的应用而言,因为有大量的用户进行访问,所以必须把应用部署到大规模的服务器集群上。然后每个应用都需要与数据库建立连接,大量的应用服务器连接到数据库,会对数据库的连接产生巨大的压力,某些情况下甚至会耗尽数据库的连接。
(4)新增业务困难
因为所有的业务都耦合在一个单一的大系统里,随着时间的发展,这个系统会变得非常的复杂,想要维护这样一个系统是非常困难和复杂的。很多工程师入职公司半年,都还不能熟悉业务,于是熟悉系统的老员工们忙得要死,加班加点干活,不熟悉系统的新员工们一帮忙就出乱,跟着加班加点地干活。整个公司热火朝天地干活,但最后还是常常出故障,新的功能迟迟不能上线。
(5)发布困难
因为单体系统一个 war 包就包含了所有的代码,新版本发布的时候,即使跟自己开发的代码一点关系没有,但就因为包含了自己的代码,以防万一,所有开发工程师都不得不跟着发布值班,结果真正更新代码功能的只有几个人,而整个部门都要跟着加班。有代码更新的同事汗流浃背进行代码冲突处理和修复发布 bug,没有代码更新的同事陪着聊天、打瞌睡、打游戏。
这些单体架构带来的困难,很多工程师自身都是有切身体会的。所以,在开始进行微服务架构重构的时候,虽然也遇到了很多挑战和困难,但是大家为了自身的利益,还是团结一致,成功实施了微服务架构重构。
微服务框架的原理
这里就不详细的给大家介绍微服务框架的原理了,我相信喜欢学习的同学,一定能够从网上找到很多学习资料,这里就简单的给大家列举一些开源的微服务框架。
(1)Spring Cloud Alibaba
大家可以参考官方地址:https://spring.io/projects/spring-cloud-alibaba/,也可以参考GitHub上的地址:https://github.com/alibaba/spring-cloud-alibaba。
Spring Cloud Alibaba是阿里巴巴开源的微服务框架,现在可以说是开源领域比较流行的明星框架。
首先,Spring Cloud Alibaba并不是一款纯碎的RPC框架,它是一款微服务治理框架,也就是说无论是你想自研微服务框架还是直接使用开源的微服务框架,那么使用Spring Cloud Alibaba都可以做到开箱即用,并且也可以做到向Spring Boot和Spring Cloud的向下兼容。
其次,Spring Cloud Alibaba是Spring Cloud和Spring Boot的超集,也就是说只要能够运用它们的业务场景,Spring Cloud Alibaba都是能够支持的。
然后,Spring Cloud Alibaba针对阿里巴巴生态体系下的分布式中间件框架的使用和落地都是非常友好的,也就是说你想去使用阿里巴巴中间件团队开源的中间件能力,那么未来Spring Cloud Alibaba都会去支持。
最后,Spring Cloud Alibaba是一款开发微服务的神器,研发人员可以基于它去构建一套体系化的微服务架构,从而实现分布式架构。
总之,假如你的企业需要做架构转型,无论你是去做上云升级,还是要做业务重构,从而微服务化,还是你要做云原生技术升级,那么Spring Cloud Alibaba都是你的最佳选择。
Spring Cloud Alibaba目前最新的版本为2021.0.4.0,这个版本有一个比较大的改动,那就是支持高版本的Spring Cloud Stream,比如3.2.5,也就是说开发人员可以在这个版本使用Spring Cloud Stream提供的函数式编程,并使用函数式编程去完成消息的生产和消费,并且可以同时支持RocketMQ、RabbitMQ、Kafka和Redis,这样开发人员可以进一步的提效。
Spring Cloud Alibaba目前支持Sentinel、RocketMQ、Dubbo、Seata、Spring Cloud Gateway、Zuul、Spring Cloud(也包括它的所有的能力,比如多种注册中心Consul、Eureka、ZooKeeper和Nacos)。
(2)Spring Cloud
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子,它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
总之Spring Cloud是一个全家桶的微服务框架,大家一定要好好的把它的原理给吃透。
(3)Dubbo
Dubbo也是阿里巴巴开源的微服务框架,目前最新的版本为Dubbo3.1.3,可以说更新版本的速度非常的快。
当然现在很多公司都停留在Dubbo2.0阶段,所以说大家还是需要将版本给升上来,这样才能够体现新的功能。
关于Dubbo3的新特性,以及Dubbo3的核心原理,本公众号和视频号会重点去带着大家去分析。
(4)Sofa RPC
Sofa RPC是蚂蚁金服开源的一套分布式微服务框架,其实本质上它也是一套类似于Spring Cloud的全家桶,但是它本质上是聚合了蚂蚁金服分布式中间生态的能力,这一点其实和Spring Cloud Alibaba是类似的。
(5)Motan
Motan是新浪微博开源的微服务框架,大家如果感兴趣的话,自己也可以去研究一下。
(6)servicecomb
准确说应该是Apache ServiceComb,它是华为开源的微服务架构的技术解决方案,目前已经捐献给Apache基金协会。https://github.com/apache/servicecomb-java-chassisc
总之,现在微服务架构领域比较成熟的技术解决方案非常的多,大家可以按需去选择和学习。
我相信现在很多企业都有上要上云的需求,也就是将自己的业务服务托管到云上,比如阿里云。阿里云为了方便大家去上云,提供了一套完整的微服务架构技术解决方案,也就是说你需要按照它提供的技术规范去改造,从而就可以使用它提供的微服务治理能力,也就是我们常说的商业化能力。
这些商业化的能力都是有对应的开源版本的,比如RocketMQ和Nacos,都是开源版本,但是假如你现在需要升级为商业化版本,你就可以直接使用Spring Cloud Alibaba,先使用开源的中间件,然后就可以无缝的升级为商业化版本。
当然Spring Cloud Alibaba确实是一款微服务架构的神器,但是它还是有很多能力是具备的,需要开发人员去定制化开发。当然,沿用Spring Cloud Alibaba改造分布式中间件的架构模式就可以定制化很多分布式中间的能力,这个都可以借鉴的。
曾经在我的团队当中就借用Spring Cloud Alibaba的架构思想将原有的RPC框架进行升级改造,从而实现一个服务可以完成双注册中心和RPC框架之间的上下兼容。
这个中兼容确实很重要,假如你的业务服务已经在使用旧的RPC框架,并且已经使用很多年了,这个时候你去升级技术,你不可能在第一阶段就将所有的业务服务改造完成,再整体上线,这个不太现实。
这个时候,你就需要梳理一部分服务,优先完成改造,但是无论你怎么尝试去做到高内聚低耦合,你都会存在新老服务相互依赖的业务场景,这个时候你就需要去做折中的改造,需要将新的服务,在新旧注册中心同时注册服务,从而新旧服务都可以订阅该服务。但是这个改造又不能对业务的侵入性太高,所以这个时候就需要按照Spring Cloud Alibaba的架构模式,重新重构旧的RPC框架的使用方式,这样即使整个团队的Spring Cloud Alibaba框架要升级,也不影响改造的框架的同步升级。
总之,大家可以在自己的项目中去多多落地Spring Cloud Alibaba,才能从实战项目中去多总结和复盘该微服务治理框架的优势和缺点。
本人写过技术类书籍“Spring Cloud Alibaba微服务架构实战派上下册,所以在该领域还是沉淀了很多,所以大家有什么疑问可以随时的找我去沟通”
总结
微服务架构既不是良药,也不是毒药,它是一把双刃剑,咱们架构师在选择落地的过程中,一定要充分的发挥它的优势,而尽量的用最低的成本去业务中落地,毕竟实战中才能总结经验。
本人在B站已经开通UP主,会定期的更新技术原理和实战类的视频,最近在做“Nacos核心原理及案例分析”的视频,详细介绍可以参考文章“免费的微服务架构实战体系化课程——Nacos核心原理及案例分析”。