【SACC 2015现场报道】10月22日-24日，第七届中国系统架构师大会(SACC)在北京盛大召开。从2009年到现在，我们伴随着中国系统架构师大会走过了七个春秋，从最早的500人规模逐年升级到现在的2500人规模，这些年我们目睹了整个IT架构的变迁，也见证了中国IT圈内一波又一波的架构师成长之路。
▲2015中国系统架构师大会直播地址：http://oa.it168.com/topic/2015/10-20/SACC2015/
小米Open-Falcon：让所有的“中间阶层”有所选
大会第三日以“互联网+运维实践”为主题，在上午的DevOps专场上，小米运维平台研发负责人来炜与大家分享了小米公司开源的互联网企业级监控系统——Open-Falcon的实践经验。
▲小米运维平台研发负责人来炜
监控系统是整个运维环节，乃至整个产品生命周期中最重要的一环，事前及时预警发现故障，事后提供翔实的数据用于追查定位问题。来炜表示，监控系统作为一个成熟的运维产品，业界有很多开源的实现可供选择。当公司刚刚起步，业务规模较小，运维团队也刚刚建立的初期，选择一款开源的监控系统，是一个省时省力，效率最高的方案。之后，随着业务规模的持续快速增长，监控的对象也越来越多，越来越复杂，监控系统的使用对象也从最初少数的几个SRE，扩大为更多的DEVS，SRE。这时候，监控系统的容量和用户的“使用效率”成了最为突出的问题。
据来炜透露，小米在早期一直采用zabbix，不过随着业务的快速发展，以及互联网公司特有的一些需求，现有的开源的监控系统在性能、扩展性、和用户的使用效率方面，已经无法支撑。因此，小米在过去的一年里，从互联网公司的一些需求出发，从各位SRE、SA、DEVS的使用经验和反馈出发，结合业界的一些大的互联网公司做监控，用监控的一些思考出发，设计开发了小米自己的开源企业级监控系统：Open-Falcon。
▲Aggregator
对于来炜和他的团队来说，Open-Falcon的目标是做最开放、最好用的互联网企业级监控产品。其特性包括：
·强大灵活的数据采集：自动发现，支持falcon-agent、snmp、支持用户主动push、用户自定义插件支持、opentsdb data model like(timestamp、endpoint、metric、key-value tags)
·水平扩展能力：支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询
·高效率的告警策略管理：高效的portal、支持策略模板、模板继承和覆盖、多种告警方式、支持callback调用
·人性化的告警设置：最大告警次数、告警级别、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期
·高效率的graph组件：单机支撑200万metric的上报、归档、存储(周期为1分钟)
·高效的历史数据query组件：采用rrdtool的数据归档策略，秒级返回上百个metric一年的历史数据
·dashboard：多维度的数据展示，用户自定义Screen
·高可用：整个系统无核心单点，易运维，易部署，可水平扩展
·开发语言：整个系统的后端，全部golang编写，portal和dashboard使用python编写。
▲Gateway——跨数据中心
只要安装了falcon-agent的机器，就会自动开始采集各项指标，主动上报，不需要用户在server做任何配置，这也和zabbix有很大的不同。这样做的好处，就是用户维护更方便，覆盖率高。当然这样做也会server端造成较大的压力，不过open-falcon的服务端组件单机性能足够高，同时都可以水平扩展，所以自动多采集足够多的数据，反而是一件好事情。
不过对于监控系统来讲，历史数据的存储和高效率查询，永远是个难题，这是由于：
1. 数据量大：目前小米的监控系统，每个周期，大概有2000万次数据上报(上报周期为1分钟和5分钟两种，各占50%)，一天24小时里，从来不会有业务低峰，不管是白天和黑夜，每个周期，总会有那么多的数据要更新。
2. 写操作多：一般的业务系统，通常都是读多写少，可以方便的使用各种缓存技术，再者各类数据库，对于查询操作的处理效率远远高于写操作。而监控系统恰恰相反，写操作远远高于读。每个周期几千万次的更新操作，对于常用数据库(MySQL、postgresql、mongodb)都是无法完成的。
3. 高效率的查：我们说监控系统读操作少，是说相对写入来讲。监控系统本身对于读的要求很高，用户经常会有查询上百个meitric，在过去一天、一周、一月、一年的数据。如何在1秒内返回给用户并绘图，这是一个不小的挑战。
来炜介绍说，Open-Falcon在这块，投入了巨大的精力。我们把数据按照用途分成两类，一类是用来绘图的，一类是用户做数据挖掘的。
对于绘图的数据来讲，查询要快是关键，同时不能丢失信息量。对于用户要查询100个metric，在过去一年里的数据时，数据量本身就在那里了，很难1秒之类能返回，另外就算返回了，前端也无法渲染这么多的数据，还得采样，造成很多无谓的消耗和浪费。我们参考rrdtool的理念，在数据每次存入的时候，会自动进行采样、归档。我们的归档策略如下，历史数据保存5年。同时为了不丢失信息量，数据归档的时候，会按照平均值采样、最大值采样、最小值采样存三份。
打车软件背后的配置管理难题
不到三年时间，打车软件之间的烧钱大战便彻底改变了大家的消费习惯，街边招手打车这种传统模式逐渐被取代，有了手机软件，轻轻一按即可轻松出行。作为国内专车市场的拓荒者，创立于2010年的易到用车，通过400电话和互联网提供专车服务的时间要早于Uber和滴滴快的。易到用车担任架构师刘宇在会上与大家进行了打车领域高效可靠的配置管理系统设计与实现技术的分享。
▲易到用车担任架构师刘宇
随着移动出行领域的飞速发展，传统的基于文件的配置管理方式已经不能满足需求，甚至在多环境、多应用的场景给工程师制造了巨大的麻烦，降低了工作效率。配置文件和代码耦合在一起，多环境下配置不一致，增加了开发、测试人员的工作量。新建环境难度大，不利于业务的飞速增长。而由于配置引起的错误，造成不能迅速定位的问题。各个应用独自管理配置，效率低。
因此，易到用车在此背景下，自主研发了易到配置管理系统。据刘宇介绍，它具有如下特点：
▲网络拓扑
1.所有环境配置项集中管理，一处修改，相应机器实时同步更新
2.分布式设计，高可用，对于服务器宕机，升级等情况对客户端透明
3.所有系统资源统一管理，以引用的方式提高配置效率
4.支持API方式修改、发布配置项
5.分环境，分应用的权限控制
6.管理后台提供对环境，应用，资源和配置项的添加，查询WEB接口，并支持快速环境复制，以及批量配置等功能提高配置效率
7.配置项支持多次改动，一键发布，及时生效的功能
8.客户端部署方便，使用简单，支持C，PHP语言接口
9.基于每个配置项的日志功能，方便定位问题和审计
▲总体架构
其配置中心角色分别部署于各个环境，刘宇建议，每个环境至少部署两个中心，每个中心的地位对等。配置中心可同时为多个环境服务，即Cache不同环境的配置项。中心缓存每个环境配置项及其变化信息(Changelist)，Changelist用于实现Agent的增量更新，以daemon方式运行。
客户端Agent&SDK方面，Agent与配置中心之间以TCP长连接通信，以私有协议获取配置项，消息体以json做为格式;Agent定时轮询中心配置项的变化，并进行增量更新;Agent的缓存以共享内存的方式实现;App通过SDK在Agent的缓存中查找配置项;Agent以daemon方式运行
