从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个大型分布式系统。
Squid配置管理系统。这个系统的主要作用是：用来管理公司的Squid缓存设备。因为我们对于服务质量的苛刻要求，公司在全国一、二、三线城市基本都做了节点的覆盖，并在部分城市间设有专线，而且在海外一些国家也设置了缓存节点，设备总数上万台。每天运维人员都需要通过该系统来操作这些缓存设备以实现对频道内容的新增、变更、优化等等。配置内容基本上在5分钟之内就可以下发到设备上并生效。
资源配置管理系统。这个系统的主要作用是： 它是公司IT资源管理的核心，很多系统的运行都需要通过与它进行API的交互来完成，它还管理并配置智能流量路由系统SSR的调度策略，以及管理并配置公司的各种软硬件资源等等。同样该系统要与全网的上万台设备进行数据交互，而且更大的难点在于，这些资源之间存在复杂的运算关系，逻辑复杂度之高可想而知。
计费采集系统。这个系统的主要作用是：收集全网用于提供加速服务的设备所产生的计费数据。截止到2012年第三季度，我们的活跃用户数已经超过1千个，每个用户下面的频道数不等，多的几百个，有的甚至上千，少的几个，几十个，全网的频道好几万个，由于我们采用每5分钟采集一次数据的方式，所以一天就是288个采集点，而一个频道可能分布在多台设备上，这样几万个频道一天算下来，所采集到的数据有十几亿条，采集的数据之庞大对系统处理能力的要求很高。
开发这些支持CDN服务的大型分布式系统，主要难点有两个：大并发的处理和大数据量的处理。这两个难点在技术上有一个共同点：如何保证服务的稳定性，保证系统7X24持续可用。当时我规划的一种方式是：边缘设备通过域名解析，以负载均衡的方式（便于容灾切换），将文件和数据收集到集中的集群当中来，同时为了保证系统的持续可用，对整个集群做异地的容灾和定期的轮岗服役及演练。同时为了保证集群两边数据的一致性，定时在集群之间做数据准确性校验和修正工作。如下图所示：
系统简要逻辑图
查看本栏目更多精彩内容：http://www.bianceng.cnhttp://www.bianceng.cn/Servers/cloud-computing/