“让专业的人做专业的事”，畅捷通与阿里云的云原生故事

嘉宾 | 畅捷通技术总监 熊昌伟

畅捷通公司是用友旗下成员企业，专注服务于小微企业，对于各种经营阶段、各种类型的小微企业，畅捷通都有产品及功能覆盖，而且付费模式也非常灵活。

小微企业客户有一个特性，他们的需求会特别广泛，而且很杂，但有时用到某个产品的某类功能时，又会用得比较深入，这种情况对于畅捷通这样标准的 SaaS 服务厂商提出了比较大的挑战。因此，畅捷通后端需要有一个非常大的微服务群，为客户的业务提供支撑和保障。

早在 2012 年，畅捷通就采用了微服务的混合云模式。2015 年，畅捷通开始将线下 IDC 机房全部转换为公有云为主、IDC 为辅的运营模式。到 2016 年，畅捷通公司基于阿里云原生产品开始了云原生实践。如何借助阿里云强大的 IaaS 和 PaaS 能力去构建新一代的 SaaS 企业应用，从而给客户提供更好、更强的服务，这是畅捷通一直在思考和实践的方向。最终，畅捷通选定阿里云企业级分布式应用服务 EDAS 作为应用托管平台，并开始下一代产品的微服务开发。

为什么选择阿里云？畅捷通的优势在于业务创新，在技术服务和技术能力的建设方面，公司倾向于选择一个可靠的基础架构平台，因为 To B 业务的稳定性是核心能力，阿里云是我们的第一选择。

畅捷通从云原生中获得技术红利

从一开始，畅捷通就把云上所有的应用都部署在云上的 ECS，后来出于成本的考虑，又把一部分研发环境和测试环境也搬到云上容器环境，再借助监控服务 ARMS、消息服务、日志服务等阿里云应用，以全面的云原生产品来提升产品研发的效率与云上应用的稳定性。

起初，整体的研发模式都非常流畅，效率也很高，但是基于微服务架构构建的业务系统在带来便利性和灵活性的同时，也给开发团队和测试团队带来了挑战。因为微服务之间存在依赖，开发人员无法在本地完成开发和测试工作，必须依赖于一套完整的开发测试环境，但同时每一套环境又是隔离的，这时就出现了三个痛点：

1.  事多，多个开发人员和测试人员共享一套环境，相互影响，调试困难。由于微服务上下层之间的依赖，整个环境中如果有一个微服务出现问题，整套环境就无法正常运行。当开发人员想要调试某个功能，又必须依赖于上下游的应用调用时，就会非常痛苦。每增加一个微服务，整体的研发效率就在下降，这时的情形与畅捷通最初采用微服务的目标背道而驰。

2.  钱多，构建多套开发测试环境，成本很高。最初因为要加快进度，畅捷通会不计成本地部署多套环境（一套完整的微服务调用环境，一年费用 10 万元起步），这个成本对于正常盈利的公司而言还是比较高的。当时畅捷通的研发环境和生产环境的比例达到了 4:1，这是什么概念呢？就是畅捷通需要用花费 400 万的研发环境，才能研发出只要 100 万就能支撑所有客户的生产环境运行的应用，这个费用比非常可怕。

3.  人多，继续增加环境，维护成本激增。在开发人员和测试人员随研发目标扩大而持续投入的情况下，为了匹配微服务的需要，畅捷通需要持续地增加后台环境的维护人员，比如运维人员或者相关的保障人员，而且他们的工作量成倍增加，因为微服务出现故障或者环境出现问题是非常常见的事情。

针对畅捷通的痛点，阿里云设计并发布了 EDAS 全链路流控方案：在微服务场景下可以对流量进行精确控制，在入口处根据指定的特定特征进行流量识别，同时标识会随着这个请求在整个执行流程中进行流转，这样可基于标识对微服务调用进行精确控制，将特殊流量引导到特定的应用版本或环境。

但此时还存在两个问题，一个问题是后端的微服务经常变更，前端的应用和服务也在变更，那么变更该如何解决？另外一个问题是，每个开发人员都在服务层做调试和发布，当他们把应用发布到服务器上再进行调用，成本其实还是比较高的。

针对这些问题，畅捷通跟阿里云的技术人员一起调研试错，最后引入了微服务网关策略，搭建了基于全链路流量的开发测试环境。通过微服务网关的能力，就能实现前端和后端全部灰度的模式，按需部署，节省了大量的费用，也大大降低了运维成本。同时也实现了多环境的相互隔离，业务之间相互不影响。

在实践过程中有一个独特的亮点，这就是微服务网关策略中的端云联调模式：开发人员可以将本地的笔记本电脑直接注册到整个微服务环境中去，这样开发人员就可以在本地完成上下游业务的验证和测试，极大地提高了开发人员的工作效率以及提交代码的质量。而在这之前则是在本地模拟一些请求，去猜测微服务环境上下游的调用是否正常，并没有一个真正的环境去做验证。现在通过端云联调模式，就可以方便地将笔记本电脑注册到整个服务中心去进行流转，包括前端应用的管控。与此同时，通过微服务网关策略，不但实现了南北向的流量管控，也实现了东西流量的全管控模式。

另外，畅捷通还通过接入阿里云应用实时监控服务 ARMS，让畅捷通微服务体系具备了监控能力。在此之前，由于畅捷通 SaaS 产品涉及到的业务链路极为复杂，当用户反馈系统出现 bug 或者性能存在问题之后，团队需要耗费非常长的时间在错综复杂的链路之间定位故障源以及性能瓶颈。

但是，接入 ARMS 之后，通过全链路信息排查、应用实时诊断等工具，可以将定位问题的工作量降到之前的 50%以下，极大地提升了团队的工作效率。后续随着畅捷通各条业务线的持续迭代，在整体微服务架构中也逐步引入了消息服务 MNS、应用高可用服务 AHAS、性能测试 PTS 等一系列云原生产品，进一步解放了团队的生产力，使得畅捷通有更多的精力来更好地满足用户的业务需求。

通过引入成熟和稳定的阿里云原生产品方案，畅捷通的系统架构在面对复杂业务场景频繁迭代时，表现出了稳定、健壮、弹性的优势。畅捷通的研发团队也通过在实践中建立并掌握了一套方法论，形成适合自己的微服务治理机制，又继续实践着全链路灰度等全新的微服务治理思路，在降本增效的同时，也体现出畅捷通在企业管理云服务领域领先的研发管理水平。

畅捷通的业务正在高速发展中，云原生产品像一个强有力的助推器，加速企业的创新升级。

云原生的价值

对于大部分企业来说，IT 是有历史包袱的。因为原来 IT 应用的部署模式都是竖井式的，不同应用由不同的软件开发商提供，系统之间存在网络安全隔离，又存在协同关系，网络、应用拓扑非常复杂。所以企业 IT 上云是一个系统性的工程，原来的应用可能还需要结合云上提供的虚拟机、网络和存储的特点进行必要的改造，不能简单粗暴的使用“原来物理机什么配置，虚拟机就什么配置。原来应用什么架构，上云后就什么架构”的这种失去“上云”优势的迁移方法，要防止为了上云而上云的做法。

云的特点就是弹性、敏捷、分布式、可扩展、自管理、自恢复，符合云特点的基础架构就可以称为云原生基础架构。云原生基础架构需要在提供自主应用程序管理的 IaaS 之上创建一个平台，这个平台要建立在动态创建的基础架构之上，以抽象出各个服务，并促进动态资源的分配、调度和扩展。

云原生是一种构建和运行应用程序的方法，它充分利用了云计算交付模型的优势，更天然的贴合云的特点。云原生既包含技术（微服务、敏捷基础设施），也包含管理（DevOps、持续交付、康威定律、重组等）。云原生是一个不断丰富的理念和技术体系，它在基础架构、应用程序和管理上都将深刻的影响和改变企业云的未来。

在不断的应用探索并持续改进后，云原生产生了多种核心价值。

第一，其优势和云的传统优势（如：资源池化、规模化、稳定性和弹性）完美结合，为企业提供了更好的产品和服务，降低了上云成本，并驱动了云的进化，如：软硬一体协同优化。同时通过 aPaaS、云原生中间件、微服务、服务网格、Serverless 等产品技术，让云平台的使用界面不断上移，进一步降低云的使用成本，提升技术效率。

第二，云原生技术基于开放的标准，极大地改变了用户心智，促进了企业和开发者对新技术和上云的接受度，云原生成为云和客户交互的新界面。

另外，云原生是应用研发和系统运维最佳实践的组合，正在重塑软件生命周期，通过基础设施云化、核心技术互联网化、应用数据化以及智能化来赋能企业，为企业带来降本增效、快速迭代、智能运营的优良基因，促进了企业生产力，助力企业的业务增长和商业创新，帮助企业快速获取技术红利，加速企业的数字化升级。

运维已去，技术运营已来

因为云原生能力带来的价值，很多企业开始基于云原生做技术架构调整。不仅如此，为了让云原生更好地发挥价值，企业的组织架构也会随之改变。在畅捷通，技术运营成为组织中很重要的一部分。

很多人都在好奇技术运营与运维的差异？其实技术运营是从被动的运维保障转变为主动的技术服务。有价值的技术运营领域应该思考：如何促进产品的成熟？如何发挥技术的价值？如何为用户带来感动？如何让技术运营成为企业的另一个核心竞争力？所以，技术运营更多时候应从财务管理的视角进行判断和决策，从商业角度控制成本投入和分配，以获取资源利用率和营收最大化。换句话说，就是从客户真正的痛点出发，平衡的驾驭“稳定、安全、容量与成本”，用创业的心态做产品，用花自己钱的心态去运营。

此时的技术运营，不再是传统的运维管理方式，他们会从业务目标出发来评估投入产出比，包括资源利用率，甚至是每个客户的资源成本等，将成本意识完全植入到研发运行体系中，让每一位开发人员都清晰的了解到业务资源的成本，以合理申请公司 IT 资源，最终提升整体的研发能效。

而畅捷通之所以会产生运维岗位向技术运营岗位的升级，与云原生有很大的关系。

回顾畅捷通的上云历程，上云之前，畅捷通更关注系统的稳定运行。上云之后，畅捷通会更关注产品如何给客户提供更好的体验。以前我们的 DBA、网工每天忙得不可开交。但上云之后，大家在基础层面的工作大大减少。比如从数据库的角度，之前大家会关注数据库的主备切换、备份等，现在大家则关注数据库的运行状态是否健康、慢 SQL 如何优化等。另外在组织架构层面也有很大的变化，上云之后，基础运维的同学大幅减少，而开发人员规模大幅增加。现在畅捷通的组织里已经没有运维岗位，他们被大家称为“运维开发”。

在这个升级变化的过程中，实质上还是思维方式的一种转变。

这个转变包含很多层面，既包括员工的意识形态及技能的变化，也涵盖着公司对于整个技术运营部门的重新定位和价值升级。

原来在做更新上线时，都是由运维同学来负责，经常需要几个通宵，而现在则是由研发同学通过自助来完成，不再是人力的交付，而是系统的支撑和平台的交付，这也是熊昌伟在畅捷通转型过程中一直在给大家传递的理念。所谓系统性交付，就是一项工作你可以做一次、两次，但如果你需要重复做三次以上时，你就应该把这部分工作交付给产品或系统，让它们来实现这些能力。

转型不易，对于运维岗位而言是很大的挑战。

首先是思维模式的转变，原来运维是作为系统保障的核心，每个运维人员的后面都会跟着很多的开发人员和测试人员。现在随着云原生产品的引入，整个运维的压力大大降低，对于运维人员来讲就需要提供更多的主动服务，来体现自己的价值，而不是被逐渐边缘化。

其次，运维人员要有意识地进行转型，现阶段我们有很多人开始做技术运营，后面大家还会更深入地成长为系统架构师、云架构师等。对于每款引入的云原生产品，技术运营都要成为公司里最懂怎么运行好这款产品的专家。云产品的使用方式跟传统的产品肯定不一样，比如上云之前不需要关注网络层面，但是上云之后有了一些新的概念，比如跨区访问、计量模式等。虽然阿里云可以保障云产品基本的稳定性，但是这款产品如何用得更好、当前状态怎么样、产品在服务客户过程中是否稳定等，是需要技术运营人员持续思考和不断实践的。

云原生，让专业的人做专业的事

熊昌伟不断强调：“我理解的云原生，就是让专业的人做专业的事。”

聚焦于自己的专业领域，把自己的优势发挥到最强。不要为了表面上的“省钱”（实践证明自建相较于云产品的综合成本更高），而忽视了服务的稳定性。

很多技术人员会说自建更好，我们有自己的技术人员，为什么不自己建一个平台或者搭一个服务器？

实际上，如果自建出现了任何故障，一样会给整个业务带来很大的损伤；另外从技术人员的角度，他们“只管生不管养”，虽然交付不容易，但运行过程中持续的维护和使用才是更核心的。在我们已知的行业过往中，除非技术人员非常厉害，否则自建的成本非常高，而且最后基本都“惨败收场”，转而开始使用云产品。

畅捷通是业内较早意识到云原生产品价值的企业之一，也是较早践行云原生理念与落地云原生实践的企业。

畅捷通为什么相信云原生？

首先，畅捷通愿意拥抱新趋势，在公司层面会对业内前沿的技术和产品做调研，切实地计算出云产品与自建之间的差距，包括成本、效率、稳定性等维度。比如“如果用阿里云原生的产品，投入是多少，产出是多少，盈亏平衡点等”。经过测算发现，随着业务量的增加，整体的红利会越来越大。

其次，畅捷通在做产品选型时非常的谨慎，因为这个产品一定要经得起考验，才会让大家感受到产品的好处，从而建立信任。这其实也是畅捷通选择阿里云的原因，因为阿里云原生产品的打磨和在复杂场景中的历练都非常的完善，产品使用过程中给畅捷通团队的整体感受也很好。技术运营团队其实是阿里云与畅捷通之间的一道桥梁，让好的产品在畅捷通发挥出它的价值，同时也让畅捷通享受到云原生的技术红利。

变化莫测、快速前行的时代，我们既要敬畏技术，更要拥抱新的趋势。就像我们身边的通信行业里，很多手机厂商用最好的硬件、屏幕、芯片甚至是按键等来打造出一款优秀的手机，并完成生态的建设。云原生的模式也是如此，越早加入这个趋势，无论对于公司业务的支撑和助力，还是个人的可持续发展，都会更加长远。

接下来，畅捷通也计划通过 EDAS+ACK 的方案，实现快速的容器化以达成基础设施及应用的全面云原生。EDAS3.0 是一套 PaaS 平台，提供 ECS 与 K8s 的双模应用部署交付模式，助力畅捷通从容实现容器化落地。

原文链接：“让专业的人做专业的事”，畅捷通与阿里云的云原生故事