亲宝软件园·资讯

展开

构建安全可靠的微服务 | Nacos 在颜铺 SaaS 平台的应用实践

阿里巴巴云原生 人气:1

作者 | 殷铭  颜铺科技架构师

本文整理自架构师成长系列 3 月 19 日直播课程。 关注“阿里巴巴云原生”公众号,回复 “319”,即可获取对应直播回放链接及 PPT 下载链接。

**导读:**颜铺科技因美业⽽⽣,“颜铺专家”是一款专为美业商家打造的 SaaS 平台,为了能够给商户提供更加安全、稳定、高效的平台,我们在技术方面做了很多尝试,经过几次演进,使系统变得更加稳定可靠。今天主要和大家分享一下颜铺科技的架构演进,以及 Nacos 在颜铺的应用实践。

单体应用时代

上图是我们单体服务时的架构图,分为会员、订单、门店等很多模块,看架构图似乎还算清晰,但是真正看到包结构的时候,真的令人头秃!改起代码特别头痛。单体服务带来的几个挑战:

  • **发布周期慢:**虽然当时业务量不算大,但是代码量很大,业务迭代牵一发而动全身,每次发布需要对整个服务进行重新编译打包部署。特别是最开始在没有构建工具的时候,发布过程需要一堆的命令,总有一种 **“一顿操作猛如虎,定睛一看原地杵” **的感觉。

  • **协同效率低:**合并冲突多,有时你在前面开心地写代码,而别人在解决冲突时,可能也在开心地删着你的代码,增加了很多的沟通成本。

  • **稳定性差:**当服务出现故障时,可能会导致整个系统不可用,并且系统不易扩容,当商户搞促销时,可能活动结束了,服务器还没有扩容完成。

  • **性能差:**因为在单体服务内,有些开发人员为了满足自己的业务,很多无关业务间 SQL 联表查询,并且不关注性能问题,导致线上时常出现负载警告。 

另外,我们在业务上也遇到了一些挑战:

  • **业务转型: **2018 年 6 月,我们公司决定从泛行业转向美业,需要打造一个专为美业商户提供技术支持的丽人 SaaS 平台。

  • **快速占领市场:**业务的转型带来了更多商户的新需求,如果不能快速迭代,则意味着被市场淘汰。因此,提升开发效率,快速占领市场成为我们急需解决的问题。

  • **商户体验差:**随着越来越多的商户入住,性能和可靠性的问题逐渐显现,出现问题,不能及时修正,商户体验变得很差,违背我们客户第一的原则。 

综上所述,我们认为进行服务化改造刻不容缓。

微服务改造

经过公司开发同学们的讨论,我们最终决定分两步进行改造: 服务化改造 1.0 的目标:

  • 用最小的改造成本先将新、旧商户平台进行打通,做到功能上的快速迁移;
  • 业务抽象,将新旧商户中心的公用部分进行抽象,并优化旧商户中心的代码逻辑,为后续的业务中台建设做好铺垫。

服务化改造 2.0 的目标:初步建设业务中台,让平台的各种能力能够快速复用、快速组合,支持业务更快捷地探索与发展。 服务化改造 1.0 预期效果:

  • 我们希望老商户中心在对外提供服务的同时,还能够作为提供者,对新商户中心提供服务支持;
  • 新商户中心仅对外提供服务,不直连数据库,业务层只对美业的特殊逻辑进行处理。 

因此,我们的想法是:新商户中心直接调用旧商户中心通过 Controller 暴露出的接口,进行远程调用,于是我们决定尝试使用 Spring Cloud 。

 服务发现选型:

  • Consul 支持服务发现的同时,支持 kv 存储服务,因为我们想做一个配置中心的 KV 存储,所以想利用 Consul 做一个尝试;
  • 服务健康检查相对更为详细;
  • 在我们选型的期间,突然出现了 Eureka 2.x 开源工作宣告停止的消息,虽然后来发现,这个对我们并没有什么太大的影响,但在当时的决策让我们最终选择了 Consul 。 

服务化改造 1.0 架构图:

服务化 1.0 我们的技术改造方案是:将旧的商户中心注册到 Consul 上面,新商户中心到 Consul 上获取服务器列表,通过 Feign 进行远程调用,打通了新老商户中心的功能。 

经过服务化 1.0 的改造,我们解决了如下几个问题:

  • **功能快速完善:**旧商户中心的功能快速迁移到了新的商户中心,并完成对美业的适配;
  • **迭代速度加快:**新商户中心大部分功能,能够通过旧商户中心进行修改兼容,为后续的业务中台的抽象打好基础;
  • **性能优化:**业务开发的同时,我们对旧商户中心的老代码进行优化,性能和稳定性均有所提高。 

但服务化 1.0 改造后,还是有一些挑战没有解决:

  • **发布周期依旧不够快:**大部分代码还是在就商户中心,业务迭代依然牵一发而动全身;
  • **协同效率没有提高:**在代码冲突多,沟通成本高的同时,又出现了令开发同学头痛的新老业务的兼容问题;
  • **维护成本:**Consul 是 Go 语言开发的,不易维护;Spring Cloud 在开发过程中体验不佳,在写业务的同时,还要摸索 Spring Cloud 的最佳实践,花费了一些时间去做 Spring Cloud 的基础建设。

于是我们决定开启,服务化 2.0 的改造。 服务化改造 2.0 的预期效果:

  • 完成业务中台的初步建设,将模块重新划分,抽象为独立服务;
  • 新、旧商户中心服务仅做自己的业务兼容,并对外暴露接口;
  • 新增专门支持 H5、小程序 的 C 端 WEB 服务。 因 Spring Cloud 体验不佳,我们决定服务化改造 2.0 尝试使用 Dubbo 作为基础服务的 RPC 远程调用框架,因此我们要对注册中心进行选型。 

首先,注册中心我认为应该具备的基本功能 :

  • 服务注册及时被发现,异常时的及时下线;
  • 服务管理,能够手动恢复/剔除服务;
  • 健康检查,检测服务是否可用;
  • 元数据管理;
  • 注册中心保证自身的高可用。

**Zookeeper

加载全部内容

相关教程
猜你喜欢
用户评论