单体应用改造成Spring Cloud微服务的简单总结

共 2498字,需浏览 5分钟

 ·

2021-11-07 01:36


源 /         文/ 

花了几天时间把项目由Spring Boot单体项目改造成了Spring Cloud微服务。说实话,目前的业务量远远用不着上微服务,单体完全Hold得住,不过架不住上面领导天天BB,算了,搞吧搞吧。

最难的部分不是技术

单体转微服务花时间最多的是反而不是在技术升级上。而是业务划分上,以前的强关联关系需要重新梳理,该分离分离,该聚合聚合,相信我当你去拆分单体应用的时候最头疼的一定是这个。有两个平台业务太复杂了直接先不拆,先接进去。一切本着最简化开发的思路进行,因为上面没给多少时间去折腾这个,搞开发真的很卑微。

技术改造过程

在原单体项目中,我们有类似spring-boot-dependencies管理依赖的项目,项目所有的类库以及依赖版本都有该项目管理。如果要集成Spring Cloud的一系列组件只需要把Spring Cloud的依赖管理项目加进去就行了。
            <dependency>
                <groupId>org.springframework.cloudgroupId>

                <artifactId>spring-cloud-dependenciesartifactId>
                <version>2020.0.3version>
                <type>pomtype>
                <scope>importscope>
            dependency>
如果你需要集成Spring Cloud Alibaba的话,需要额外添加对应的依赖管理项。

Nacos VS Consul

Nacos是Spring Cloud Alibaba中的核心项目之一,在微服务架构中充当注册中心和配置中心,网上教程很多,现在用户也非常多,功能也非常强大。玩了一天单机都没什么问题,再搞集群的时候出了点问题没解决掉(自己水平问题),就切换到Consul了。Eureka不考虑了,不维护了已经。
至于为什么用Consul,首先没有用过,好奇心比较重;第二点Consul作为该领域的知名产品,在很多大企业都有过落地实践,好像微博用过这个。功能对比Nacos来说弱一些,配置管理、服务注册与发现、管理UI一个也不少。由于Spring Cloud抽象了二者的配置,所以切换除了更换依赖、改下配置之外没有其它的障碍。
这里额外科普一下,居然身边的都不知道HashiCorp公司。它可是开源界的独角兽,估值已经超过50亿美金,他们的开源产品质量都很高,其旗下明星级产品包括Consul、Nomad、Vault、Vagrant、Packer、Terraform等等。他们的CEO创始人刚刚辞职,重新干起了码农,因为他太喜欢写代码了。

OpenFeign

服务间调用,目前可选的技术栈不太多。Dubbo体系不太想用,只有OpenFeign可选了。如果你想把Feign用明白就必须认真学一下OpenFeign的调用流程,有能力的话看下源码。这个网上教程很多,不过令牌中继网上的教程不清不楚的,我花了点时间搞定了。在上一篇公众号中有详细的讲解。

负载均衡

Robbin 作为负载均衡的组件目前也不维护开源了。好在Spring 官方自己实现了新的负载均衡组件:
        
            org.springframework.cloud
            spring-cloud-starter-loadbalancer
        

熔断

Hystrix也过时了,目前只有阿里的Sentinel和Resilience4J可选,既然我抛弃了Nacos、那就用Resilience4J吧,熔断、限流、重试都有,不过功能没有Sentinel的多,你可以根据需要选用。另外,Resilience4J大量使用函数式编程,想精进函数式编程的必须学一下它的源码。

安全

关于安全的改造,还是基于Spring Security来干,只不过是把认证和授权鉴权分开来干了。单独搞了个服务用来注册登录、角色权限资源管理,负责发放JWT。其它的服务都是OAuth2.0资源服务器,只需要对JWT进行验证即可,目前并没有完整接入OAuth2.0协议,因为需要一个过渡期,架构并不是一蹴而就的。这个前面已经花了三篇文章分享了改造的一些要点,有兴趣可以去看一下,大部分人估计就卡这里了。

网关

首先Spring Cloud Gateway用起来很简单,但是没有UI,路由持久化也需要自己去实现。总之不太好用,好在它不难使用。如果没有时间的话,拿它凑合一下。如果有时间,我得试试Apache Apisix或者Orange。这些网关都基于Openresty,无论是性能还是功能都比Spring Cloud Gateway要强大的多。

日志

日志我想大部分人使用EFK体系,我这里选择了Loki,Sidebar模式集成起来非常简单。如果后面有需要再上EFK。

链路追踪

目前Jaeger、Zipkin、Skywalking都不错,比较倾心Skywalking,还没有研究。

分布式事务

爬!目前不需要!真等出了问题再说。分布式事务需要结合业务来看,如果业务划分比较合理,分布式事务并不是一个必选项。

总结一下

其实Spring Boot 单体项目改造成Spring Cloud微服务体系总体是非常平滑的。工程量最大的是业务划分,并不是技术体系的选择和集成,我的思路就是强关联的先放到一起,公用的独立服务。组件集成花不了多少时间。另外要有个过渡期,要循序渐进,先改造边缘业务试水,稳定压倒一切。

ON SALE


推荐阅读


PROMOTION



女程序员做了个梦,神评论。。。


火遍全国的网络热梗“yyds”,创造者被判刑3年


这3名院士已被撤销院士资格!


END


顶级程序员:topcoding

做最好的程序员社区:Java后端开发、Python、大数据、AI


一键三连「分享」、「点赞」和「在看」


浏览 36
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报