作者：王康白山联合创始人兼产品副总裁。王康先生主要负责产品改进与升级、产品开发过程控制与进度协调、产品设计改进与定期优化、产品生命周期管理。他带领团队实现了白山首款产品CDN-X的多项创新，降低了CDN的使用门槛，极大地拓展了CDN客户资源，提升了白山的品牌价值，促进了整个CDN市场的拓展和发展。王康先生曾就职于网宿科技，担任公司产品及售前高级总监，负责技术团队运营；10年CDN行业从业经验，专注于提升产品输出的高质量、高可靠性。王康先生拥有三项发明专利。现在很多公司都在做松耦合，因为随着业务的发展，需求的增加，紧耦合系统的问题会逐渐凸显，越来越严重。以云分发行业为例，其属性正在逐渐发生变化。过去，很少有人生产内容，绝大多数人消费内容。云分发主要集中在下游流量。但随着全民直播的兴起，云分发变成了云互动；物联网的发展使得物与物的数据通信成为主要手段。例如，智能家居每天产生数千条数据，但只有一小部分被消费。随着VR的爆发，用户产生的数据会逐渐从图片、视频变成VR内容。基于此，我们可以预期上行流量会逐渐增加，并逐渐超过下行流量，这将成为对基础网络架构的巨大挑战。用户需求和基础网络环境的快速变化，使得我们需要越来越快地实现需求。然而，紧耦合的系统给研发带来了诸多困难，使得功能的实现越来越耗费精力和时间。因此，在白山成立之初我就决定构建一个“乐高式松耦合”的架构来搭建整个产品体系，像搭积木一样灵活。一、传统难点（一）需求积累，收敛周期长。许多初创公司在成立之初就采用了残酷的成长模式。原则是越早越好。紧耦合架构可以很好地满足这些要求。可以快速搭建CMDB和资源管理平台，配置自动化、门户、监控等功能。但是随着功能的增加和需求的发展，这个系统也逐渐变得一团糟。当一个新的需求出现时，他们需要为它做大量的硬编码动作，收敛周期越来越长。(2)“老中医”资源的浪费在紧耦合的系统中，一个看似无关的小改动极有可能引发大bug；为了防止出错，系统只能设计得越来越复杂。例如，为了防止客户端挂掉，研发通常会为其添加一个守护进程；当daemon进程不稳定时，新进的研发人员普遍的解决办法是再增加一个daemon进程，这样系统会越来越臃肿。这时候，公司往往需要经验丰富、了解系统全局的“老中医”来对平台进行改造。作为核心资产的“老中医”忙于救火和技术攻关，很难抽出时间进行系统改造。2、如何解决“乐高式松耦合”架构快速实现与需求实现越来越慢的矛盾？最后，百山的产品架构注重解耦，有利于平台快速迭代，减少系统间依赖，打通不相关项目，高效支持运营交互，保证服务质量。(1)第一层松耦合架构以白山云分发CDN-X系统为例，其基础核心是运营。为了让运营支撑系统能够通过解耦让公司的研发和运营灵活运作，需要进行第一层抽象。运营支撑系统抽象为五个组成部分，包括：客户管理、计费信息、资源管理、运营监控和配置管理。并对这五个组件进行画像，根据运营场景确定边界、输入输出、描述用户场景。几个组件通过消息总线交换命令，通过标准复位接口交换数据；同时将这五个组件投入到实际开发中，根据不同的类型进行实例化。（第一层松耦合架构）（2）第二层松耦合架构完成第一层的解耦之后，我们发现第二层还可以继续抽象。以配置管理系统为例，可以抽象出四个部分。生成配置：主要负责配置生成和配置到git仓库；分发控制：管理灰度发布过程；执行分发：分发接收到的指令，并通过一些工具（如：salt、ansible、httpget）上报给上面的组件；执行测试：调用已经编写好的测试用例库，测试这个配置分发过程的最终效果。（第二层松耦合架构）运营支撑系统中的各个组件始终可以进行抽象，抽象的概念贯穿于整个设计平台。将核心组件的设计进一步抽象为工厂模型或单例模型，形成针对不同特性服务和场景的可插拔架构，只需要编写极小的落地代码即可获得整个运营支撑服务。(3)构建原则组件即服务研发中的每个人都是架构师。接到研发需求后，不是去研究输入、输出和边界，而是去了解业务。根据情况输出需求文档，与业务方确认，根据需求设计架构。每个组件不再是一个功能，而是一个服务，都有自己的服务对象；研发人员从负责代码质量、输入输出，演变为负责服务质量。事件组件化在最初的设计过程中，我们发现很多运行中的动作并不是平台上的动作，而是由事件组成的。如果这些事件通过自动化来完成，则需要付出很大的努力。以节点上线的自动化为例：它包括自动化的端口扫描、监控、安装、配置下发管理，甚至可以在当前系统平台上增加自动化，为用户提供服务。组件自动化后，如果打包成事件，会浪费不必要的人力成本。如果事件组件化，运维管理人员可以方便地在平台上拖拽、引用、标准化组件，通过拖拽和配置工作实现整体自动化。数据聚合管理系统数据往往是运行中判断的标志，通过数据与数据之间的关系形成组件。由于数据源之间的API不同，连接API的时间会过长。我们对机房质量、监控负载、慢速比、卡顿率等数据进行梳理，部分进行二次改造，通过统一的接口调用做成数据聚合管理系统。示例共享节点自动上线（运维完成流程）。在这个过程中，运维人员完成了很多组件，例如：配置管理、内测外测、进入覆盖区域等；然后引入多个数据源进行跟踪。活动模板完成后，运维人员只需选择上架节点、覆盖方案和区域，其余流程由系统自动完成。这个模板也可以根据需要不断修改。比如丢包率组件可以随时添加，不影响业务。许多公司也在开发相同的事件管理系统，不同之处在于它们管理动作；并且我们发现动作完成后往往需要人工跟踪。鉴于此，我们将事件做成一个完整的生命周期，并引入数据源来跟踪异常服务状态码。在完成本次活动的过程中，运维人员所需要的操作已经从编写脚本、人工分析简化为在模板上拖拽、引用组件、根据经验设置阈值，甚至可以使用其他活动模板来完成事件。3.松散耦合需要坚持的细节(1)Keepitsimple随着时间的推移和功能的不断增加，系统难免会显得复杂，而这种复杂有很多是我们自己操作造成的，正如上面提到的“守护进程”的一个例子，当使用复杂的解决方案来解决问题时，它往往会使系统膨胀。如果保证系统具有容错性，当组件无法正常运行时，系统可以自动恢复，这个问题就会得到简化。以消息管理机制为例，强消息管理机制需要确认消息确实可以被每个设备接收和执行。我们对此进行了改进，使消息像病毒一样传播。每个设备可以向周围的5-6个设备发送消息。即使中途有一个失败，其他设备也会重新传输给这个设备。这样的容错性保证了系统可以简单自动的实现强研发、强追踪等功能。(2)基于平台构建应用例如在大数据平台上构建应用，研发人员在开发组件时不需要考虑数据库设计和瓶颈优化问题，只需要对接数据聚合平台，大大提高了研发效率。（3）持续迭代以Facebook为例，目前每秒可处理12亿张图片；而它的第一版系统只允许用户上传图片并保存在数据库中，而且系统只能维持3个月；随着活跃用户的增加，其后端的压力不断增加，所以存储改为二进制存储；Facebook的每一次迭代都不是为了一个特定的目标，而是为了解决商业痛点。所以在开发之初，我们只需要考虑需求和业务，设计一个足够简单的方案，然后不断迭代以满足新的需求。4.带来的变化(1)快速引入新特性我们采用P2P消息管理机制结合收敛算法，将文件删除时间从5分钟提高到0.7秒。我们没有对系统做大的改动，只是更换了消息机制，使用现在的基础通讯机制和基础数据，过去做的优化和UI还是可以用的。在引用这些新功能时保持轻量级，对其他组件的影响很小。(2)开发效率高例如游戏交互过程中的数字包交互是业界公认的难点。我们目前正在尝试引入开源的TCP代理软件，并规划新的应用服务类型。软件按照指定的打包方式放置到指定的位置即可自动发布，同时调用其他组件接口支持新的业务Monitor并编写配置生成逻辑实现业务配置的自动化。只需编写非常轻量级的登陆代码，整个组件登陆后即可服务运行。(3)提高运维自动化在定位问题时，如果人工跟踪一般是“是或否选择”的串行计算，在事件管理系统中，进行并行计算，即调用监控系统判断是否nodeisnormal;调用第三方数据进行及时检测，判断当前节点服务是否正常；调用客户App数据验证服务质量；使用ELK系统分析日志，准确快速定位问题，分析时间从10分钟大幅缩减至3分钟。
