当前位置:   article > 正文

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

springboot 将单体架构改造成微服务

dc8a98939e44a102197800cf7fd1695c.gif

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

最难的部分不是技术

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

技术改造过程

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

  1. <dependency>
  2.                 <groupId>org.springframework.cloud</groupId>
  3.                 <artifactId>spring-cloud-dependencies</artifactId>
  4.                 <version>2020.0.3</version>
  5.                 <type>pom</type>
  6.                 <scope>import</scope>
  7.             </dependency>

如果你需要集成Spring Cloud Alibaba的话,需要额外添加对应的依赖管理项。

Nacos VS Consul

Nacos是Spring Cloud Alibaba中的核心项目之一,在微服务架构中充当注册中心和配置中心,网上教程很多,现在用户也非常多,功能也非常强大。玩了一天单机都没什么问题,再搞集群的时候出了点问题没解决掉(自己水平问题),就切换到Consul了。Eureka不考虑了,不维护了已经。

至于为什么用Consul,首先没有用过,好奇心比较重;第二点Consul作为该领域的知名产品,在很多大企业都有过落地实践,好像微博用过这个。功能对比Nacos来说弱一些,配置管理、服务注册与发现、管理UI一个也不少。由于Spring Cloud抽象了二者的配置,所以切换除了更换依赖、改下配置之外没有其它的障碍。

0726598070df495d7b83892e793f89e4.png

这里额外科普一下,居然身边的都不知道HashiCorp公司。它可是开源界的独角兽,估值已经超过50亿美金,他们的开源产品质量都很高,其旗下明星级产品包括Consul、Nomad、Vault、Vagrant、Packer、Terraform等等。他们的CEO创始人刚刚辞职,重新干起了码农,因为他太喜欢写代码了。

OpenFeign

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

负载均衡

Robbin 作为负载均衡的组件目前也不维护开源了。好在Spring 官方自己实现了新的负载均衡组件:

  1. <dependency>
  2.             <groupId>org.springframework.cloud</groupId>
  3.             <artifactId>spring-cloud-starter-loadbalancer</artifactId>
  4.         </dependency>

熔断

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

Spring Cloud Feign如何实现JWT令牌中继以传递认证信息

2021-10-20

94374e6c3c4ebb0b66c6b2eb83df7e78.png

使用Spring Security 资源服务器来保护Spring Cloud 微服务

2021-10-19

7776fdebb992d65386c09204bedf638e.png

初步认识微服务中的资源服务器

2021-10-18

e392e635ac6f0018489fc8d3fd9eebaf.png

cf594efe2cfa126d94dec64b72be11a9.gif

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Monodyee/article/detail/501903
推荐阅读
相关标签
  

闽ICP备14008679号