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

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

最难的部分不是技术

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

技术改造过程

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

   

    

     

      

     
     

      

       <dependency>
      
     
    

     

      

     
     

      

                       <groupId>org.springframework.cloud</groupId>
      
     
    

     

      

     
     

      

                       <artifactId>spring-cloud-dependencies</artifactId>
      
     
    

     

      

     
     

      

                       <version>2020.0.3</version>
      
     
    

     

      

     
     

      

                       <type>pom</type>
      
     
    

     

      

     
     

      

                       <scope>import</scope>
      
     
    

     

      

     
     

      

                   </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 官方自己实现了新的负载均衡组件：

   

    

     

      

     
     

      

       <dependency>
      
     
    

     

      

     
     

      

                   <groupId>org.springframework.cloud</groupId>
      
     
    

     

      

     
     

      

                   <artifactId>spring-cloud-starter-loadbalancer</artifactId>
      
     
    

     

      

     
     

      

               </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

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

2021-10-19

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

2021-10-18