总部位于苏州的这家国内物流 SaaS 公司，曾经借助云原生能力，实现了技术架构的全面降级。
海管家，这家创建于 2015 年的年老科技公司，不到 8 年工夫，将服务的客户数量做到超百万级，遍布寰球各地，成长速度让人咂舌。
得益于公司在 AI、大数据、云计算等技术畛域的超前布局，海管家率先在物流畛域推出多个变革性产品，为港口、船公司、货代企业、船代企业提供当先的零碎解决方案和数据对接服务，在无纸化码头零碎畛域有丰盛的我的项目教训。
目前，海管家的产品矩阵涵盖了可视化、电子单证发送、SaaS 货代操作系统、跨境业务零碎、获客和 IM 工具为主的综合性 SaaS 服务，并提供在线报关、线上代订舱（E-BOOKING）等公共物流服务。
那么，海管家又是如何通过云原生，在物流 SaaS 畛域实现业务翻新，为客户提供更加稳固、牢靠的服务的，并进一步帮忙企业优化资源和人力老本的呢？带着这些疑难，咱们深刻带你理解这家企业的技术改革历程。
业务增长太快，研发效力如何解决？
随着海管家 SaaS 业务的上线，注册认证用户呈现出了爆发式的增长，用户的应用场景也不断扩大。在这个过程中，SaaS 的用户应用体验变得愈发重要，如何在用户规模高速增长的同时能够保障 SaaS 的稳定性、敏捷性，SaaS 的微服务开发效率如何保障，这些都给研发团队带来了肯定的挑战。
挑战一，业务迭代实效变慢、开发效率变低
最大的挑战之一，来自于 SaaS 用户场景需要的减少，越来越多的性能期待发开、公布上线，对迭代频率的要求越来越高，但因为 SaaS 服务技术架构偏差于传统的利用开发方式，不可能像微服务、模块化架构一样，进行多线并行开发。同时，对于利用公布，短少灰度公布能力，为了保障业务稳定性，每次公布客户只能抉择在凌晨的业务低峰期进行，开发、运维、测试同学苦不堪言，对于发版无损公布能力的需要声音越来越大。
海管家 · 开发架构演进示意图
挑战二、业务架构与技术架构能力不匹配
还有一个，疫情物流承压、货代数字化成大趋势，但数字化如何在国内物流落地，海管家提出了本人的规范。
“国内物流跨境角色多、链条长，一个提供国内货代服务的 SaaS 公司如果要做数字化，一条产品线至多要晋升 20% 到 30% 的效力，才可实现商业的疾速复制、扩张以及落地，进而能力倒退为 SaaS 公司的外围业务线。“海管家 CEO 金忠国示意。
而且除了效力问题，国内货代的 SaaS 服务的实质其实是要解决信息、数据和相干业务的标准化问题，而这些须要行业各相干角色的协同，单个公司靠本人无奈解决标准化问题。
作为一家 SaaS 服务商，海管家抉择的倒退门路是跟着行业节奏逐点击破、连点成线，最终达到平台的交融。
能够预计，将来国内物流 SaaS 平台企业肯定会以『数据服务化』、『全渠道服务化』和『新业务拓展麻利化』的融合与翻新为倒退方向，这对团队的业务架构能力与技术架构能力提出来比拟高的要求。
海管家 · 业务架构示意图
此外，在市场需求的疾速变动下，产品性能翻新和迭代效率问题也是对技术架构的一大挑战。
“咱们是国内第一批云住民”
”咱们从守业的一开始就基于云原生，能够说是国内第一批云住民，上云用云就和血液一样，云造就了咱们，也倒退了咱们。”海管家技术负责人徐红维通知鹅厂技术派。
云原生，它是先进软件架构技术和治理办法的思维汇合，通过容器、微服务、继续交付等一系列技术，实现了信息系统由烟囱状、重安装和低效率的架构向分布式、小型化和自动化的新一代软件架构的转变。
同时，云原生架构具备松耦合、分布式、高韧性三大特点，可能以业务利用为核心，充分利用云计算劣势，实现麻利交付、价值聚焦的外围指标。
“有没有发现，上述问题及现状的解法和云原生架构带来的外围能力不约而同。”
“因而，海管家很早就笃定要将次要的业务利用，包含前端 Web 容器、网关、后端微服务、大数据等等通过 Kubernetes 集群部署，以云原生的形式帮忙业务疾速迭代，灵便响应商业需要。”徐红维补充道。
微服务虽好，可不要“贪杯”哦
微服务治理平台怎么选
都在说微服务，然而微服务也要隔靴搔痒。对于微服务的治理、革新，海管家的团队更加看重的是革新的复杂度、侵入性、稳定性等方面，海管家技术团队对目前市面上的几款开源产品进行调研以及和相干团队进行深刻的沟通。
通过大量的预研后，最终抉择了腾讯云北极星（Polaris Mesh），次要看重一下几个个性：弱小的管制面、无侵入、稳定性高、丰盛的可观测能力、混合云反对、兼容 Kubernetes 等。
基于北极星（Polaris Mesh）的服务治理、流量治理、故障容错、配置管理和可观测性五大性能，以及容器服务的根底运行能力，海管家从新架构了业务的技术架构如下图。
海管家 · 服务化架构示意图
微服务开发框架选型，开放性、成熟度、普适性缺一不可
与容器化革新简直同步进行的是对微服务架构的对立。
在此之前，海管家的各个业务单元多种技术栈并存，彼此之间互相通信复杂度高，我的项目成员的交接往往要消耗微小的精力，极大水平上妨碍了业务倒退的停顿，因而微服务架构对立势在必行。
海管家经验了 2 年多工夫实现了这一项艰巨的工作，尽管投入精力微小，但收益很大，在技术框架上都有对立的规范能够遵循，各团队之间对立技术栈，研发效率成倍晋升。
关系到将来多年的技术策略，在微服务架构的选型上，开放性、成熟度、普适性规范缺一不可，思考到海管家以 Java 为次要开发语言，Spring Cloud Tencent 就成为了微服务框架的新的抉择。同时，海管家也将自研的基于 Spring Cloud + Dubbo 开发规范的根底服务框架与 Spring Cloud Tencent、Polaris Mesh 进行兼容整合。
海管家 · 微服务开发框架 SCT 性能
老我的项目与新架构之间如何平滑演进
架构的变更须要有一个演进过程。云原生其实源自于 PaaS，所以在利用云原生架构的时候，在 PaaS 层也遇到了平滑演进的问题。如何让产品和开发者即能保留以前的习惯，同时又能去尝试新的交付、开发方式？在传统的模式中，大家习惯于交付代码包，习惯于基于虚拟机的运维，而云原生时代以容器镜像作为交付载体，而运行实例则是镜像实例化容器。
无论是基于传统架构的 PaaS，还是基于 kubernetes 的 PaaS，实现次要操作都是一样的，包含：建站、公布、重启、扩容 / 缩容、下线等等，实现两套无疑十分浪费资源，也减少了保护老本，对于产品和开发者来说干的事件是一样的。所以海管家技术团队用 kubernetes 实现了所有公共局部，包含：对立元数据、对立运维操作、对立资源形象。在产品层和运维形式上，提供两种管制面。
在进行技术架构演技的过程中，会面临新老零碎并存的问题，老（遗留）零碎的架构技术栈老旧，革新、重构老本较大，海管家通过 Mesh 的形式对立解决这个问题。新零碎，Mesh 是 Pod 里的 Sidecar，但老零碎因为个别状况下是没有运行在 kubernetes 上，所以不反对 Pod 和 Sidecar 的运维模式，须要用 Java Agent 的模式来治理 Mesh 过程，使得 Mesh 可能帮忙老架构下的利用实现服务化革新，并反对新老架构下服务的对立治理。
海管家 · 新老架构平滑迁徙示意图
海管家 SaaS 研发团队意识到，随着业务倒退的向好，这些挑战也会也越来越大。
在业务疾速倒退中，既要保障好已有业务的稳定性，又要疾速地迭代新性能，并且须要保障开发的效率并不会随着业务增长而大幅升高。在新的微服务体系下，海管家的业务开发人员更加专一在业务自身，从繁冗的技术栈中脱离进去，也就能解决两大关键性的问题：零碎稳定性、研发效率。
”挪动互联网时代，谁还玩停机保护那一套“
以下是咱们在微服务摸索过程中的一些教训分享，心愿可能帮到正在浏览本文的同行。
第一，环境隔离
在理论的开发过程中，一个微服务架构零碎下的不同微服务可能是由多个团队进行开发与保护的，每个团队只需关注所属的一个或多个微服务，而各个团队保护的微服务之间可能存在互相调用关系。
如果一个团队在开发其所属的微服务，调试的时候须要验证残缺的微服务调用链路，此时须要依赖其余团队的微服务，如何部署开发联调环境就会遇到以下问题：
首先，如果所有团队都应用同一套开发联调环境，那么一个团队的测试微服务实例无奈失常运行时，会影响其余依赖该微服务的利用也无奈失常运行。
其次，如果每个团队有独自的一套开发联调环境，那么每个团队不仅须要保护本人环境的微服务利用，还须要保护其余团队环境的本身所属微服务利用，效率大大降低。同时，每个团队都须要部署残缺的一套微服务架构利用，老本也随着团队数的减少而大大回升。
此时，能够应用测试环境路由的架构来帮忙部署一套运维简略且老本较低开发联调环境。测试环境路由是一种基于服务路由的环境治理策略，外围是保护一个稳固的基线环境作为根底环境，测试环境仅须要部署须要变更的微服务。多测试环境有两个根底概念，如下所示：
1. 基线环境（Baseline Environment）: 残缺稳固的根底环境，是作为同类型下其余环境流量通路的一个兜底可用环境，用户应该尽量保障基线环境的完整性、稳定性。
2. 测试环境（Feature Environment）: 一种长期环境，仅可能为开发 / 测试环境类型，测试环境不须要部署全链路残缺的服务，而是仅部署本次有变更的服务，其余服务通过服务路由的形式复用基线环境服务资源。
部署实现多测试环境后，开发者能够通过肯定的路由规定形式，将测试申请打到不同的测试环境，如果测试环境没有相应的微服务解决链路上的申请，那么会降级到基线环境解决。因而，开发者须要将开发新测试的微服务部署到对应的测试环境，而不须要更新或不属于开发者治理的微服务则复用基线环境的服务，实现对应测试环境的测试。
尽管测试环境路由是一个绝对成熟的开发测试环境解决方案，然而可能开箱即用的生产开发框架却不多，往往须要开发者二次开发相应的性能。因而须要一个绝对欠缺的解决方案来帮忙实现测试环境路由，简化开发难度并晋升开发效率。
基于上述的想法，海管家有十几条产品线，并且产品线之间存在着盘根错节的关联，并线开发、联调等问题始终被产研团队吐槽和诟病。
基于北极星微服务引擎的能力，联合 Spring Cloud Tencent 的开发框架，与社区进行合作开发以下的计划，测试环境路由的样例实现以下图为例，一共有两个测试环境以及一个基线环境。流量从端到端会顺次通过以下组件：App（前端）-> 网关 -> 通行证核心 -> 订单交易中心 -> 领取结算核心。
海管家 · 测试环境路由示意图
为了达到测试环境路由的能力，开发工作须要做三件事件：
1. 服务实例染色（标识实例属于哪个测试环境）
2. 流量染色（标识申请应该被转发到哪个测试环境）
3. 服务路由
a. 网关依据申请的指标测试环境标签转发到对应的指标测试环境的用户核心。
b. 服务调用时，优先转发到同测试环境下的指标服务实例，如果同测试环境下没有服务实例则转发到基线环境。
其中在流量染色的环节，海管家联合着 Spring Cloud Tencent 的开发组件的能力，应用客户端染色 + 网关动静染色。
● 客户端染色（举荐）
如下图所示，在客户端收回的 HTTP 申请里，新增 X-Polaris-Metadata-Transitive-featureenv=v2 申请头即可实现染色。该形式是让开发者在申请创立的时候依据业务逻辑进行流量染色。
海管家 · 客户端染色示意图
● 网关动静染色（举荐）
动静染色是开发者配置肯定的染色规定，让流量通过网关时主动染色，应用起来相当不便。例如把区域编号 area_code=shanghai 用户的申请都转发到 feature env v2 环境，把区域编号 area_code=beijing 的用户的申请都转发到 feature env v3 环境。只须要配置一条染色规定即可实现。
海管家 · 网关动静染色示意图
第二，灰度公布
随着业务的倒退、客户需要的增多、行业利用场景的多样化，产线均匀每天几十次公布。为了不影响白天业务顶峰以及用户群体的特殊性（面对 B 端的 SaaS 零碎），每次较大发版只能抉择在凌晨业务低峰期进行。
设想一下，如果产品、研发、运维人员、中台反对人员每次都集中在早晨公布，太不人性化。
”挪动互联网的时代，谁还玩停机保护那一套呢？“
如果早晨抉择较少的人参加公布，那么当出问题的时候会『耽搁救治』的最佳时机，故障责任也不好划分。
北极星，在灰度公布这方面提供了很大的反对和帮忙，可能满足海管家现阶段灰度公布的场景：首先用户体验不能中断的业务，其次微服务业务的存在关联关系的多个微服务的个性变更。
能够基于域名拆散的形式实现全链路灰度，通过不同的域名辨别灰度环境和稳固环境。前端客户的申请通过灰度域名拜访到灰度版本的服务，通过稳固域名拜访到稳固版本的服务。
海管家 · 灰度公布示意图
灰度申请通过灰度域名接入到网关，网关通过域名辨认到灰度申请后，将申请优先路由到灰度版本的服务，并通过申请头的形式进行灰度染色。后续微服务之间，服务框架通过申请头辨认到灰度申请，会优先将申请路由到灰度版本服务，如果寻址不到灰度版本，则路由到稳固版本服务。
对于全链路灰度公布，海管家不仅须要将流量进行灰度，还须要将后端的数据库、缓存、音讯队列等等根底服务也反对灰度，这里还须要跟北极星社区进行更加深度的单干和开发。
看的远，能力走的稳
“看的远，能力走的稳。看得远映射到平台化，走的稳映射到零碎重构，这未然成为海管家的重要技术策略。”金忠国说。
“将来，咱们将持续进行云原生架构降级摸索，继续进步 SaaS 业务零碎的稳定性和敏捷性，随着对云原生架构的了解的深刻，咱们将持续与腾讯云原生团队进一步的摸索和钻研，给客户发明更多的价值。”