从2006年7月，我开始在蓝汛工作，在这些年中我历任软件工程师、高级软件工程师和团队主管，参与并主导开发了公司的Squid配置管理系统、资源配置管理系统和计费采集系统这三大系统。同时，经历了蓝汛的带宽从100G发展到1.5个T的过程；也经历了蓝汛在美国纳斯达克上市的时刻。虽然现在离开了那里，转而投身云计算IaaS平台的技术创业和开发，但是在那里积累的分布式系统开发的丰富经验，仍然令我受益良多，这篇文章就是从技术角度对这些年的一个总结。

从100G到1.5个T

我刚到公司时，公司对外服务提供的带宽刚到100G，我记得当时还专门做了T恤衫发给大家，以示庆祝。从那年开始，公司的业务每年都以70%到80%左右的速度增长。

业务的高速发展，对我们这些技术人员提出了挑战。 当时蓝汛使用基于硬件的专用物理设备，比如3DNS、CacheFlow、NetCache、Array Networks等等。客户如果需要CDN加速需求，运维人员需要登录到多种服务器上手工进行相应的配置维护，既容易出错，又效率低下。后来经过公司不断对研发的投入以及不断的创新实践，我们研发了拥有自主知识产权的流量调度管理系统—SSR（Scalable Service Routing，智能流量路由系统），以及基于Squid的缓存组件，同时开发了用来进行相应配置及下发的系统，慢慢的就不再依赖专用的硬件设备了，在大幅度降低了服务成本的同时，也让服务的开通及运维更加自动化了。这块的工作也就从瓶颈变成了推动力，推动公司的业务向前跑得更快。

现在做云计算IaaS平台，回头想一想，现在跟当初有许多的相似之处。IaaS，不也是着眼于降低企业IT运营成本，提高企业运营灵活性，同时又将IT支持人员从繁琐、低效、易于出错的物理服务器购买、上架、安装、配置、优化的过程中解放出来么？用基于API的方式，管理、调度虚拟化的资源，只要几分钟，就可以完成几十台甚至上百台云服务器的安装、部署、优化。人，可以因此享有更多自由，完成更有价值、更有创意的事情。这就是技术的力量。

三个大型分布式系统

接下来说说我当时做过的3个大型分布式系统。

1、Squid配置管理系统。这个系统的主要作用是：用来管理公司的Squid缓存设备。因为我们对于服务质量的苛刻要求，公司在全国一、二、三线城市基本都做了节点的覆盖，并在部分城市间设有专线，而且在海外一些国家也设置了缓存节点，设备总数上万台。每天运维人员都需要通过该系统来操作这些缓存设备以实现对频道内容的新增、变更、优化等等。配置内容基本上在5分钟之内就可以下发到设备上并生效。

2、资源配置管理系统。这个系统的主要作用是： 它是公司IT资源管理的核心，很多系统的运行都需要通过与它进行API的交互来完成，它还管理并配置智能流量路由系统SSR的调度策略，以及管理并配置公司的各种软硬件资源等等。同样该系统要与全网的上万台设备进行数据交互，而且更大的难点在于，这些资源之间存在复杂的运算关系，逻辑复杂度之高可想而知。

3、计费采集系统。这个系统的主要作用是：收集全网用于提供加速服务的设备所产生的计费数据。截止到2012年第三季度，我们的活跃用户数已经超过1千个，每个用户下面的频道数不等，多的几百个，有的甚至上千，少的几个，几十个，全网的频道好几万个，由于我们采用每5分钟采集一次数据的方式，所以一天就是288个采集点，而一个频道可能分布在多台设备上，这样几万个频道一天算下来，所采集到的数据有十几亿条，采集的数据之庞大对系统处理能力的要求很高。

开发这些支持CDN服务的大型分布式系统，主要难点有两个：大并发的处理和大数据量的处理。这两个难点在技术上有一个共同点：如何保证服务的稳定性，保证系统7X24持续可用。当时我规划的一种方式是：边缘设备通过域名解析，以负载均衡的方式（便于容灾切换），将文件和数据收集到集中的集群当中来，同时为了保证系统的持续可用，对整个集群做异地的容灾和定期的轮岗服役及演练。同时为了保证集群两边数据的一致性，定时在集群之间做数据准确性校验和修正工作。如下图所示：

系统简要逻辑图

对于大并发的处理来说，我们要做的：一是优化数据的读写性能，以提高单位时间内的吞吐量，二是横向扩展读写能力以提高总的处理能力。如上图，为了提升读写性能，做了读写分离的架构，而且在数据处理层、API层、数据库层都构建了扩展点。

对于大数据量的处理来说，我们要做的：一是对数据来源进行分类处理，比如会用专门的流程来处理流媒体服务器产生的数据，而用另外的流程来处理Squid服务器产生的数据。二是对数据进行多步加工，每一次加工只做很少的事情，将中间结果保留，然后再由下一阶段的处理程序在此基础上进行加工。这样环环相扣最终形成完整的可扩展的处理链条，如下所示为分阶段处理逻辑架构图：

分阶段处理逻辑架构图

另外我们会根据一些客户的需求做定制。举个例子：比如某些大客户，他们对数据实时性要求就比较高，那么我们就会采用另外的策略，开辟专用的通道，同时尽量缩短中间处理环节以减少总耗时，而且开发专有API来满足客户对于实时性数据的访问需求。

这些难点，有的来自公司内部本身的业务快速增长带来的复杂性以及处理吞吐量的要求，有的来自客户的定制化需求。开发这几个系统的经历，对我现在设计开发目前这套“云计算综合管理平台系统”很有帮助。举个例子：在开发层面，我会去想办法抽象客户的需求，在个性和通用性上取得一个平衡，对于非常个性话的需求考虑用插件化的方式接入，当该功能不再使用时即从系统中注销掉。

目前整个系统都是用Python写成，在架构上使用异步消息队列RabbitMQ中间件作为服务总线，来完成任务的异步调用以及云主机等的状态同步。由于采用Python的模块化的开发方式，对一个插件的启用或停用，只要一行代码就可以搞定。

回顾这9年多的开发历程，变的是在每个不同阶段从事不同业务的开发，但不变的依然是对系统整体不断的完善、思考和探索，经过一番摸爬滚打，积累的成果最终体现在这些代码和架构中。

云+CDN：大规模web服务必行之路

CDN解决静态内容的传送和扩展问题，但是无法解决动态内容的传送和扩展给源站带来的建设、部署和扩展上的难题，而有了云计算的支持，对于源站的动态内容扩展是一个极好的解决方案。静态内容扩展实际上就是存储和网络扩展的问题，动态内容扩展的本质是计算扩展，而计算的扩展分为横向扩展和纵向扩展，这两方面在云平台上都可以在极短的时间内完成。

之前在蓝汛积累了大量分布式系统开发和管理经验，对于我目前搭建迅达云成的云计算综合管理平台系统很有帮助。我们现在想要做到的，是帮助客户搭建一套通过代码和自动化方式驱动的、有高控制权的基础设施。我们通过云计算为客户提供资源，提供编程接口，让客户通过自动化方式完成扩展，从过去繁复的工作中快速解脱出来，实现业务的快速伸缩。

目前，我们正在致力于整合接入一些CDN系统，在此基础上进行一定的封装，屏蔽底层差异性，对外暴露统一的CDN调度的API接口，这样客户可以直接在我们的云平台上跟CDN做结合，调用一站式服务的API，从而达到带宽和计算资源的充分利用。

其实回顾下IT技术的发展历史，可以看到是围绕着计算、存储和网络这三个方面展开的，而且各自的总体趋势都是从集中式到分散式，从分散式到分布式。在分布式这个层面，必须要通过虚拟化技术，才能实现更纯粹的分布式，因为虚拟化技术会从多个层面来对数据及系统提供更加安全、有效的冗余及保护。计算虚拟化、存储虚拟化目前都已经基本实现，正在走向不断完善的过程，而以OpenFlow和SDN为代表的网络虚拟化，是整个IT业界正在跨越的另一座山峰。在当下，云结合CDN，已经可以满足大规模Web服务开发的绝大部分要求。

作者简介：董伟，9年互联网从业经验。曾就职于天极网、北京蓝汛(ChinaCache)等国内知名IT公司，历任软件工程师、高级软件工程师、团队主管等职位。现任迅达云成CTO。喜欢思考，喜欢攻克、钻研技术难点。