“乐高式松耦合”架构实战

做者：王康

白山联合创始人兼产品副总裁。
王康先生主要负责产品的完善与升级、产品开发流程把控及进度协调、产品设计改进及按期优化、产品全生命周期管理等工做。他带领团队实现白山首款产品CDN-X的多项创新，下降CDN使用门槛，极大拓展了CDN客户资源，提高了白山品牌价值，促进总体CDN市场的扩大与发展。
王康先生曾就任于网宿科技，任该公司产品及售前高级总监，负责技术团队的运营工做；拥有10年CDN行业经验，专一于提升产品输出的高质量和高可靠性。
王康先生拥有三项发明专利。

如今不少公司都在作松耦合，由于随着业务发展、需求增长，紧耦合系统的问题会慢慢凸显，并日益加重。
以云分发行业为例，其属性在逐渐发生变化。过去，极少人产生内容，绝大多数人消费内容，云分发主要如下行流量为主，而随着全民直播的兴起，云分发变成了云交互；物联网的发展使物与物的数据交流成为主要方式，例如智能家居天天会产生上千条数据，但其中只有几条会被消费；VR爆发，用户产生的数据逐渐会从图片、视频转变为VR内容；基于此咱们能够预料到上行流量将逐步增长，并逐渐超过下行流量，成为基础网络架构的巨大挑战。
用户需求与网络基础环境的快速变化，使得咱们须要愈来愈快的实现需求，然而紧耦合系统却为研发带来诸多困难，使功能实现愈来愈耗费精力与时间，因此在白山创立之初就决定作“乐高式松耦合”架构，来构建整个产品体系，像搭积木通常灵活自如。

1、 传统难点
（1）需求堆积，收敛周期长
不少创业公司在成立之初采用野蛮生长的模式，原则是越快越好。紧耦合架构能够很好的知足这些要求，他们能够快速的创建CMDB与资源管理平台，并配置自动化、portal、监控等功能。但随着功能增多与需求开发的增长，这个系统逐渐变为人心涣散。当有新需求发生时，他们须要为其作不少硬编码动做，收敛周期愈来愈长。
（2）“老中医”资源的浪费
在紧耦合系统中，看似一个没有什么关系的小改动，极有可能会引发一个重大bug；为防止错误发生，只能将系统设计的愈来愈复杂。例如为防止客户端挂掉，研发一般会为其添加一个守护进程；当守护进程不稳定时，新入职的研发经常使用的解决方案是再添加一个守护进程，这就致使了系统愈来愈臃肿。
这时候，公司每每就须要经验丰富、了解系统总体状况的“老中医”才能对平台进行改造。而做为核心资产的“老中医”在忙于救火、进行技术攻坚，很难抽出时间来进行系统重构。

2、 “乐高式松耦合”架构落地
快速实现需求与需求实现愈来愈慢的矛盾如何解决？最终白山的产品架构聚焦在解耦上，方便平台快速迭代，减小系统间依赖程度，打通无关联项目，为运营互动提供高效支持，确保服务质量。
（1） 第一层松耦合架构
以白山云分发CDN-X系统为例，其根本核心是运营。为使运营支撑系统经过解耦让公司的研发、运营灵活运转，须要进行第一层抽象。将运营支撑系统抽象为5个组件，包括：客户管理类、帐单信息类、资源管理、运营监控和配置管理。并对这5个组件进行画像，肯定边界、输入输出，按照运营场景描述用户场景。
几个组件之间经过消息总线交互指令，经过标准的reset接口交互数据；同时将5个组件投入到实际开发中，按照不一样类型作实例化。

（第一层松耦合架构）

（2）第二层松耦合架构
作完第一层解耦以后，咱们发现第二层还能够继续作抽象。以配置管理系统为例，又可抽象出4部分。

1. 生成配置：主要负责配置的生成以及配置到git仓库；

2. 分发控制：管理灰度发布过程；

3. 执行分发：分发收到的指令，并经过一些工具（如：salt、ansible、http get）汇报给上面的组件；

4. 执行测试：调用已经写好的测试用例仓库测试这一次配置分发过程的最后效果。

（第二层松耦合架构）

运营支撑系统中的各个组件均可以一直抽象下去，抽象概念贯穿整个设计平台的始末。
核心组件设计时再通过进一步抽象成工厂模式或单例模式，造成针对不一样特性服务及场景，只需编写极小的落地代码便可得到整个运营支撑服务的可插拔架构。

（3）建设原则

1. 组件即服务
   研发中人人都是架构师，收到研发需求后不是研究输入输出与边界，而是了解业务。根据状况输出需求文档，并与业务方进行确认，按照需求设计架构。每个组件，再也不是功能，而是服务，有本身的服务对象；研发人员从最初的对代码质量、输入输出负责，发展为对服务质量负责。

2. 事件组件化
   在最初设计过程当中，咱们发现，不少运营中的动做称不上是平台上的动做，而是由事件组成。若是这些事件经过自动化来完成，就须要投入大量的精力。以节点上架自动化为例：包括自动化扫描端口、监控、安装、配置下发管理，甚至能够将自动化加入当前系统平台为用户提供服务。组件自动后，若是包装成事件，将浪费没必要要的人力成本。若是将事件组件化，运维管理人员则能够在平台上方便的拖拽、引用、规范组件，经过拖拽、配置工做实现总体自动化。

3. 数据聚合管理系统
   数据每每是运营中的判断标志，经过数据与数据间的关系来组建成组件。因为数据源之间的API不一样，会致使花费过长的时间来对接API。咱们将机房质量、监控负载、慢速比、卡顿率等数据进行整理，部分进行二次转化，经过统一的接口调用，作成一个数据聚合管理系统。

实例分享－节点自动上线

（运维完成过程）

这个过程当中运维人员完成了不少组件，如：配置管理、内部测试以及外部测试、入覆盖地区等；随后引入多种数据源进行追踪。事件模版完成后只需运维人员选择需上架的节点及其覆盖方案与地区，其他过程均有系统自动化完成。
此模版还能够根据须要不断修改，例如：丢包率组件等能够随时加入，不会影响业务的进行。
不少公司也在作一样的事件管理系统，不一样的是其管理的是动做；而咱们发现每每动做完成后还须要进行人工跟踪。鉴于此咱们将事件作成一个完整的生命周期，同时引入数据源来跟踪异常服务状态码。
这个事件的完成过程当中运维人员所需的操做已经从写脚本、人肉分析，简化为在模版上拖拽、引用组件，根据经验设置阀值，甚至使用其余的事件模版来完成事件。

3、 松耦合须要坚持的细节
（1）保持简单
随着时间的推移与功能的不断增长，系统必然会出现复杂性，而这种复杂性不少是由咱们自身操做致使的，如上文提到的“守护进程”的例子，当使用复杂方案解决问题时每每会致使系统的臃肿。若是保证系统具有容错能力，组件运营不正常时系统能够自动修复，这个问题就会简化。
以消息管理机制为例，强消息管理机制要求确认消息确实能够被每台设备收到并执行。咱们对此进行了改善，使消息病毒式传播，每台设备能够向周围5-6台设备发出消息，即使中间有一次失败，还会有其余设备再次向这台设备传输。这样的容错能力保证了系统能够简单地自动实现强研发、强跟踪等功能。
（2）在平台的基础上构建应用程序
例如在大数据平台上构建应用，研发人员在开发组件时无需考虑数据库的设计以及瓶颈优化问题，只须要对接数据聚合平台，大幅提升研发效率。
（3）不断迭代
以Facebook为例，目前每秒能够处理12亿张图片；而其初版系统只能容许用户上传图片，并将其保存在数据库中，该系统只存续3个月；随着活跃用户的增长， 其后端压力不断增长，因而将存储改成二进制存储方式；Facebook的每一次迭代都不是为了某一特定目标，而是为了解决业务上的痛苦。
因此最开始作开发时，咱们只须要考虑需求与业务，设计足够简单的方案，再进行不断迭代以知足新增需求。

4、 带来的变化（1） 快捷引入新特性咱们使用P2P消息管理机制结合收敛算法，将文件删除由5分钟改进至0.7秒，咱们对系统没有进行大范围改变，只是替换了其中的消息机制，利用当前基础的通信机制和基础数据，过去所作的优化与UI仍能够继续使用。引用这些新特性时保持轻量级，对其余组件几乎没有影响。（2） 开发效率高例如游戏交互过程当中的数字包交互，业内公认很难作到。目前咱们正在进行尝试，咱们引入开源的TCP代理软件，并规划新的应用服务类型，软件按指定好的打包方式放在指定位置，就能够实现软件的自动发布，同时调用其余组件接口对新业务进行监控，编写配置生成逻辑实现业务配置自动化。只须要编写很是轻量级的落地代码，整个组件落地以后就能够服务运营。（3）运维自动化提升在问题定位时，若是人工跟踪通常是“是与否选择”的串行计算，而在事件管理系统中，则进行并行计算，即：调用监控系统，判断节点是否正常；调用第三方数据进行及时测试，判断节点当前服务是否正常；调用客户App数据验证服务质量；使用ELK系统分析日志，精准、快速的定位问题，分析时间由10分钟大幅度缩减为3分钟。