技术开发 频道

单体架构转向微服务架构— (基础篇)

  【IT168 技术】前言

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

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

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

  ·最小修改

  ·功能剥离

  ·数据解耦

  ·迭代替换

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

  Spring Cloud

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

单体架构转向微服务架构— (基础篇)

  Spring Boot

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

  Netflix Eureka

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

  Netflix Hystrix

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

  Netflix Zuul

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

  Config Server

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

0
相关文章