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

颜铺科技因美业⽽⽣，咱们的产品“颜铺专家”是一款专为美业商家打造的 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 的预期效果：

一、完成业务中台的初步建设，将模块从新划分，抽象为独立服务；
二、新、旧商户中心服务仅作本身的业务兼容，并对外暴露接口；
三、新增专门支持 H五、小程序 的 C 端 WEB 服务。

因 Spring Cloud 体验不佳，咱们决定服务化改造 2.0 尝试使用 Dubbo 做为基础服务的 RPC 远程调用框架，所以咱们要对注册中心进行选型。

首先，注册中心我认为应该具有的基本功能 ：

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

Zookeeper :
一、不能保证每次服务请求都是可达的，当 zk 集群 master 挂掉时，须要进行选举，在选举期间中，服务是不可用的。
二、不支持跨机房的路由，好比 eureka 的 zone，当前机房不可用时，能够路由到其余机房。
三、“惊群效应”， zk 的节点过多的时候，当 service 的节点发生变动，会同时通知到客户端，瞬时流量有可能将网卡瞬间打满，而且会有重复通知的问题。

Nacos :
一、注册中心部分更侧重于可用性；
二、服务发现与服务管理
三、服务元数据的管理
四、动态配置管理

在此期间，咱们也关注到了 Spring Cloud Alibaba。阿里巴巴技术经受多年“双十一”的考验，其性能和稳定性是值得信任的。Spring Cloud Alibaba 的组件开源社区活跃度很高，而且比起国外开源项目更容易交流。其组件由 Java 语言开发，对咱们来讲更易维护，在出现问题时可以更快地定位问题进行修复。并且与阿里云配合，更加容易上云，好比 Nacos 能够与阿里云的 MSE 和 ACM 配合，将注册中心及配置管理所有上云。

所以，咱们决定拥抱阿里技术栈。

服务化改造2.0架构图：

咱们将以前的模块直接抽到基础服务之中，新增了 会员、订单、门店 等服务做为Provider，暴露本身的Service，并注册到 Nacos 上。新商户中心服务作美业业务逻辑的处理，旧商户中心服务作泛行业的业务处理，C端服务同理对外提供服务。经过 Dubbo 进行远程调用。

经过服务化 2.0 的改造，效果以下：
一、服务器成本下降30%：20+台服务器，由4核16G 降配到2核8G；
二、系统可靠性提高80%：load 告警明显减小，线上的问题修正可以快速修复，完成部署；
三、代码冲突减小75%：由于边界有了基本各自维护，冲突显著减小；
四、发布迭代效率提高50%：以前5我的每一个迭代开发评估可完成30个点，如今可完成45个点左右。

Nacos落地实践与问题分析

Nacos 在咱们公司处理作注册中心以外，配置管理也对咱们提供了很好的服务。下面说一下，Nacos 咱们的使用状况，以及咱们遇到的问题。

首先是使用状况：
一、部署方式：开发/测试环境单机部署，生产环境 3 台集群部署；
二、版本：生产环境从 0.9.0 开始使用，目前生产环境使用的版本为 1.1.4 ；
三、使用时间：2019 年 3 月份开始在生产环境下使用；
四、服务数量：线上 20+ 台服务器，提供了 600+ 个服务；
五、稳定性：一年的时间里没有出现大的问题，而且平滑升级；
六、兼容性：新老服务，在咱们公司不管是 Spring 4.3+ 的工程，仍是 Spring Boot 的工程均兼容良好。

Nacos 注册中心：

一、服务注册：将后端服务注册到 Nacos，经过 Dubbo 进行调用。目前开发环境中咱们正在测试Seata，而且也将 Seata 服务注册到 Nacos 上；
二、Namespace：服务统一注册到 public 中。

Nacos 配置管理：

每一个服务设置独立的 Namespace 。

一、服务的配置文件信息：application.properties 所有配置到 Nacos，工程的配置文件仅保留 Nacos 相关配置；
二、业务层的 KV 配置：好比业务开关，属性默认值，定时任务配置等；
三、MQ Topic 的动态配置：Binlog 服务采集动态发送到在 Nacos 配置的 topic 及其须要的表信息；
四、Sentinel 的规则配置：Sentinel 限流规则持久化到 Nacos 。

问题描述：

2019 年 12 月 31 日，下午 3 点 15 分左右，线上忽然出现大量服务告警，Dubbo 服务出现报错，整个过程持续约 3 多分钟。各个业务组当天均没有任何发布，数据库状态也良好。

经过日志发现，报错缘由是门店服务没法调用。而门店服务日志，出现问题的时间段内，没有任何的调用记录。系统恢复正常时，出现了不少服务注册的通知。

所以，咱们将问题瞄准了 Nacos。查看 Nacos 的日志发现，在系统恢复过程当中，有大量的服务正在上线。

就在排查的过程当中，线上忽然又出现了以前相同的告警，Nacos 上的服务列表开始大量变成不健康的状态，因而咱们紧急重启了线上的 Nacos ，在这期间又经历了一个 3 分多钟的惊魂后，再次恢复了平静。

问题分析：
一、两次出现的问题均是门店服务，但出现问题期间 JVM 和数据库的运行状态均良好。
二、报错信息都是 Dubbo 调用超时，且出现问题期间，门店服务没有任何流量进入。
三、出现问题时，注册在 Nacos 上的服务开始大量不健康。恢复正常时，这些服务又开始上线，说明出现问题时，服务被下线又从新上线。

综上，咱们开始怀疑是网络缘由形成的。

问题确认：

通过排查，发现咱们的服务大多部署在 阿里云华东 1 可用区 B ，只有门店服务和 Nacos 集群没有部署在可用区 B ，说明这段时间可用区B与其余区之间的发生了网络隔离。

因而，咱们在可用区 B 紧急部署了门店服务，以后没有再出现问题。

通过与阿里云的沟通确认于北京时间 2019 年 12 月 31 日 14:05 分左右开始，部分用户反馈阿里云华东 1 地域可用区 B 部分网络出现异常，影响部分云资源访问。

问题复盘：
一、问题出现：下午 3 点多，忽然连续出现的服务告警， Dubbo 服务出现报错；
二、Nacos：Nacos 服务列表里大量服务出现不健康的状态；
三、网络不通：可用区 B 与其它区网络不通，致使服务没法调用；
四、紧急部署：在 B 区部署缺失的 门店服务；
五、恢复正常。

问题思考：
一、服务部署：应用服务和Nacos建议多机房部署，即便在云上可用区之间也须要考虑；
二、容灾：问题出现时，可用区 B 并无部署 Nacos，但可用区B内的服务之间依然能调通，且可以读到 Nacos 上的配置。所以，咱们认为 Nacos 以及 Dubbo 的容灾策略都是值得信赖的。

回顾与展望：

“颜铺专家”通过不断地快速迭代，帮助美业商家⾼效快捷地管理门店，进行经营数据分析，数据化管理门店，建⽴完善的会员周期管理体系，为美业商家在经营管理中，提供⼀体化的解决方案，将美业传统的门店经营模式进⾏互联网升级。截止到目前咱们累计服务 3000 多个品牌，1.1W + 个⻔店。

咱们提供了店务管理系统、会员管理系统、营销拓客系统、大数据决策系统、供应链管理系统、员工绩效管理系统6⼤系统能力，同时⽀持 PC 端、手机 APP 、 pos 机、 iPad 操做，满⾜⻔店多端操做需求，覆盖⻔店经营管理中的全部场景需求。

4、 将来规划

提高系统高可用

Seata ：目前咱们公司的分布式事务主要依赖 MQ 的补偿，今年准备引入 Seata 来完善分布式事务，保证数据一致性，减小开发修数据的状况。

Sentinel ：目前 Sentinel 咱们只是在商户作活动时启用，所以咱们要配置出适用于咱们公司的最佳实践，保证系统的高可用。

全链路跟踪：咱们公司如今定位问题主要靠日志和告警，作不到全链路的跟踪，因此咱们要把这部分作好，作到故障快速定位，各调用环节性能分析，以及数据分析。

异地容灾：随着来自全国各省的商户愈来愈多，咱们须要对商户的数据保障，避免数据丢失，确保服务的可靠性。

社区回馈

由于咱们的公司体量如今不大，咱们可以作到的是尽量地使用最新的版本，及时尝试新特性，对发现的问题提 issues，但咱们也但愿可以对 Nacos 开源社区尽一份咱们的力量。

做者信息： 殷铭，颜铺科技架构师，负责颜铺 SAAS 平台中间件的应用和实践，主导了平台架构在颜铺向分布式演进的全过程，目前也负责大数据在颜铺平台的实践和落地。