单体转向微服务架构-基础篇


前言

目前从事于教育行业,尽管如今用户量并不是特别多,但我们的产品有点庞大。基于目前的单体架构,有众多的弊端,由于前期用户量并不多,产品迭代不是很频繁,相应的问题并没有凸显。但是随着团队越来越大,相应的沟通成本、管理成本、人员协调成本显著增加。引起缺陷的原因组合多,导致分析、定位、修复缺陷的成本响应增高。在自动化测试机制不完善的情况下,易导致“修复越多,缺陷越多”的恶性循环。

我们一直正在关注当前的流行趋势,并试图从单体转向微服务架构。鉴于人员配比以及开发周期,我们不可能推到重构。

那么如何使用微服务改造遗留系统,我们基于以下几点考虑:

  • 最小修改
  • 功能剥离
  • 数据解耦
  • 迭代替换

首先,我们整理边缘业务,把后端服务抽离出来。新的框架使用SpringBoot + JPA(相对来说,我们有一套快速开发的脚手架);由于是前后端分离,认证采用相对简单的JWT;鉴于后期会拆分为多个服务,这里使用Zuul作为网关,Eureka作为服务注册中心。

Spring Cloud

Spring Cloud基于Spring Boot实现,使用HTTP的RESTful风格API作为调用方式。它所包含的多个子项目共同构建了微服务架构体系。

Spring Cloud.jpg

Spring Boot

在使用Spring开发时,通常需要完成Spring框架及其他第三方工具配置文件的编写,非常麻烦。Spring Boot通过牺牲项目的自由度来减少配置的复杂度,约定一套规则,把这些框架都自动配置集成好,从而达到“开箱即用”。

Netflix Eureka

Spring Cloud 的服务注册中心提供服务注册、服务发现、负载均衡等功能。

Netflix Hystrix

当某个服务发生故障之后,则触发熔断机制(Hystrix)向服务调用方返回结果标识错误,而不是一直等待服务提供方返回结果,这样就不会使得线程因调用故障服务而被长时间占用不释放,避免了故障在分布式系统中的蔓延。

Netflix Zuul

代理各模块提供的服务,统一暴露给第三方应用。提供动态路由、监控、弹性、全等的边缘服务。

Config Server

分布式架构下多微服务会产生非常多的配置文件,分布式配置中心(Config Server)将所有配置文件交由GIT或SVN进行统一管理,避免出错。

qrcode_for_gh_bf7a27ade681_258.jpg

作者: 小柒

出处: https://blog.52itstyle.com

分享是快乐的,也见证了个人成长历程,文章大多都是工作经验总结以及平时学习积累,基于自身认知不足之处在所难免,也请大家指正,共同进步。

本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出, 如有问题, 可邮件(345849402@qq.com)咨询。