作者 | 殷铭 颜铺科技架构师
本文整理自架构师成长系列 3 月 19 日直播课程。 关注“阿里巴巴云原生”公众号，回复 “319”，即可获取对应直播回放链接及 PPT 下载链接。
**导读：**颜铺科技因美业⽽⽣，“颜铺专家”是一款专为美业商家打造的 SaaS 平台，为了能够给商户提供更加安全、稳定、高效的平台，我们在技术方面做了很多尝试，经过几次演进，使系统变得更加稳定可靠。今天主要和大家分享一下颜铺科技的架构演进，以及 Nacos 在颜铺的应用实践。
上图是我们单体服务时的架构图，分为会员、订单、门店等很多模块，看架构图似乎还算清晰，但是真正看到包结构的时候，真的令人头秃!改起代码特别头痛。单体服务带来的几个挑战：
**发布周期慢：**虽然当时业务量不算大，但是代码量很大，业务迭代牵一发而动全身，每次发布需要对整个服务进行重新编译打包部署。特别是最开始在没有构建工具的时候，发布过程需要一堆的命令，总有一种 **“一顿操作猛如虎，定睛一看原地杵” **的感觉。
**协同效率低：**合并冲突多，有时你在前面开心地写代码，而别人在解决冲突时，可能也在开心地删着你的代码，增加了很多的沟通成本。
**稳定性差：**当服务出现故障时，可能会导致整个系统不可用，并且系统不易扩容，当商户搞促销时，可能活动结束了，服务器还没有扩容完成。
**性能差：**因为在单体服务内，有些开发人员为了满足自己的业务，很多无关业务间 SQL 联表查询，并且不关注性能问题，导致线上时常出现负载警告。
另外，我们在业务上也遇到了一些挑战：
**业务转型： **2018 年 6 月，我们公司决定从泛行业转向美业，需要打造一个专为美业商户提供技术支持的丽人 SaaS 平台。
**快速占领市场：**业务的转型带来了更多商户的新需求，如果不能快速迭代，则意味着被市场淘汰。因此，提升开发效率，快速占领市场成为我们急需解决的问题。
**商户体验差：**随着越来越多的商户入住，性能和可靠性的问题逐渐显现，出现问题，不能及时修正，商户体验变得很差，违背我们客户第一的原则。
综上所述，我们认为进行服务化改造刻不容缓。
经过公司开发同学们的讨论，我们最终决定分两步进行改造： 服务化改造 1.0 的目标：
服务化改造 2.0 的目标：初步建设业务中台，让平台的各种能力能够快速复用、快速组合，支持业务更快捷地探索与发展。
服务化改造 1.0 预期效果：
因此，我们的想法是：新商户中心直接调用旧商户中心通过 Controller 暴露出的接口，进行远程调用，于是我们决定尝试使用 Spring Cloud 。
服务发现选型：
服务化改造 1.0 架构图：
服务化 1.0 我们的技术改造方案是：将旧的商户中心注册到 Consul 上面，新商户中心到 Consul 上获取服务器列表，通过 Feign 进行远程调用，打通了新老商户中心的功能。
经过服务化 1.0 的改造，我们解决了如下几个问题：
但服务化 1.0 改造后，还是有一些挑战没有解决：
于是我们决定开启，服务化 2.0 的改造。
服务化改造 2.0 的预期效果：
首先，注册中心我认为应该具备的基本功能 ：
Zookeeper :
Nacos :
在此期间，我们也关注到了 Spring Cloud Alibaba 。阿里巴巴技术经受多年“双十一”的考验，其性能和稳定性是值得信任的。Spring Cloud Alibaba 的组件开源社区活跃度很高，并且比起国外开源项目更容易交流。其组件由 Java 语言开发，对我们来说更易维护，在出现问题时能够更快地定位问题进行修复。而且与阿里云配合，更加容易上云，比如 Nacos 可以与阿里云的 MSE 和 ACM 配合，将注册中心及配置管理全部上云。
因此，我们决定拥抱阿里技术栈。
服务化改造 2.0 架构图：
我们将之前的模块直接抽到基础服务之中，新增了 会员、订单、门店 等服务作为 Provider，暴露自己的 Service，并注册到 Nacos 上。新商户中心服务做美业业务逻辑的处理，旧商户中心服务做泛行业的业务处理，C 端服务同理对外提供服务。通过 Dubbo 进行远程调用。
通过服务化 2.0 的改造，效果如下：
Nacos 在我们公司处理做注册中心之外，配置管理也对我们提供了很好的服务。下面说一下，Nacos 我们的使用情况，以及我们遇到的问题。
首先是使用情况：
Nacos 注册中心：
Nacos 配置管理：
每个服务设置独立的 Namespace 。
问题描述：
2019 年 12 月 31 日，下午 3 点 15 分左右，线上突然出现大量服务告警，Dubbo 服务出现报错，整个过程持续约 3 多分钟。各个业务组当天均没有任何发布，数据库状态也良好。
通过日志发现，报错原因是门店服务无法调用。而门店服务日志，出现问题的时间段内，没有任何的调用记录。系统恢复正常时，出现了很多服务注册的通知。
因此，我们将问题瞄准了 Nacos 。查看 Nacos 的日志发现，在系统恢复过程中，有大量的服务正在上线。
就在排查的过程中，线上突然又出现了之前相同的告警，Nacos 上的服务列表开始大量变成不健康的状态，于是我们紧急重启了线上的 Nacos，在这期间又经历了一个 3 分多钟的惊魂后，再次恢复了平静。
问题分析：
综上，我们开始怀疑是网络原因造成的。
问题确认：
经过排查，发现我们的服务大多部署在 阿里云华东 1 可用区 B，只有门店服务和 Nacos 集群没有部署在可用区 B，说明这段时间可用区 B 与其他区之间的发生了网络隔离。
于是，我们在可用区 B 紧急部署了门店服务，之后没有再出现问题。
经过与阿里云的沟通确认于北京时间 2019 年 12 月 31 日 14:05 分左右开始，部分用户反馈阿里云华东 1 地域可用区 B 部分网络出现异常，影响部分云资源访问。
问题复盘：
问题思考：
回顾与展望：
“颜铺专家”经过不断地快速迭代，帮助美业商家⾼效快捷地管理门店，进行经营数据分析，数据化管理门店，建⽴完善的会员周期管理体系，为美业商家在经营管理中，提供⼀体化的解决方案，将美业传统的门店经营模式进⾏互联网升级。截止到目前我们累计服务 3000 多个品牌，1.1W + 个⻔店。我们提供了店务管理系统、会员管理系统、营销拓客系统、大数据决策系统、供应链管理系统、员工绩效管理系统 6⼤系统能力，同时⽀持 PC 端、手机 APP 、pos 机、iPad 操作，满⾜⻔店多端操作需求，覆盖⻔店经营管理中的所有场景需求。
提升系统高可用
**Seata：**目前我们公司的分布式事务主要依赖 MQ 的补偿，今年准备引入 Seata 来完善分布式事务，保证数据一致性，减少开发修数据的情况；
**Sentinel：**目前 Sentinel 我们只是在商户做活动时启用，因此我们要配置出适用于我们公司的最佳实践，保证系统的高可用；
**全链路跟踪：**我们公司现在定位问题主要靠日志和告警，做不到全链路的跟踪，所以我们要把这部分做好，做到故障快速定位，各调用环节性能分析，以及数据分析；
**异地容灾：**随着来自全国各省的商户越来越多，我们需要对商户的数据保障，避免数据丢失，确保服务的可靠性。
社区回馈
因为我们的公司体量现在不大，我们能够做到的是尽可能地使用最新的版本，及时尝试新特性，对发现的问题提 issues，但我们也希望能够对 Nacos 开源社区尽一份我们的力量。
**作者信息：**殷铭，颜铺科技架构师，负责颜铺 SAAS 平台中间件的应用和实践，主导了平台架构在颜铺向分布式演进的全过程，目前也负责大数据在颜铺平台的实践和落地。
“阿里巴巴云原生关注微服务、Serverless 、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.