TOP100 案例标题

1. TOP100 案例标题 架构师/亿阳信通

2. 包含固定格式的内容（就是下面的各页标题，如“要分享什么”）包含固定格式的内容（就是下面的各页标题，如“要分享什么”） • 本案例以国内某电信运营商一个大型故障告警项目为例，介绍了一个实时流分布式计算的解决方案。该方案的本质是一个基于CEP(Complex Event Processing，CEP)的事件驱动架构（EventDrivenArchitecture，EDA）解决方案，但是由于国内电信运营商的个性化需求，使得该方案有了更高的挑战。 • 通常CEP系统的特点是：1、输入事件量大，系统吞吐量大且要求弹性扩展；2、处理判断规则复杂；3、输出实时性要求高； • 本案例新增挑战：1、规则变化后，实时生效；2、规则变化频繁且规则相关性（时间维度，处理节点间）复杂；3、多路（多租户）并行输出 摘要

3. 案例标题 • a)案例简介 • b)　当初启动此案例时（或实施后）达到的目标 • CEP系统架构的挑战： • 全国集中、大省大容量告警查询和初始化过滤器 • 活动告警量将达到1700w~5.1亿 • 复杂过滤/排序查询 • 响应时间要求在秒级 • 支持几百的并发，几千的在线 • 目前背景告警入库<200EPS • 目前30万告警建立简单过滤器，如果有10万返回需要几分钟，复杂过滤器10分钟以上

4. 客户端： 1、几个 2、实时监控、流水窗 3、过滤器（按条件查看） 服务层： 1、实时分发 2、数据库持久化 告警源： 1、单一数据源 2、10条/s-》100条/s • DB方案：无法做到大并发读写，速度不达标，类似最早的告警监控C/S加载，十几分钟以上 • 进程内缓存方案：查询速度慢，不具备索引查询能力，不可扩展 • Hadoop Hive/HBase: 复杂查询启动时间多，基本都在几分钟以上 • 内存数据库：单写多读，负荷有集中点 • MPP DB/一体机：高昂的价格，且多适用于分析应用

5. 客户端： 1、几个 2、实时监控、流水窗 3、过滤器（按条件查看） 服务层： 1、实时分发 2、数据库持久化 告警源： 1、单一数据源 2、10条/s-》100条/s • 进程内缓存方案：查询速度慢，不具备索引查询能力，不可扩展

6. 客户端： 1、几个 2、实时监控、流水窗 3、过滤器（按条件查看） 服务层： 1、实时分发 2、数据库持久化 告警源： 1、单一数据源 2、10条/s-》100条/s • 内存数据库：单写多读，负荷有集中点

7. 单进程设计方案 方案描述：将所有告警存储在一个Server中，客户端与均与该服务通信。 优点：设计简单，开发快 缺点：扩展性差。

8. 分布式master-worker设计方案 方案描述：使用自己开发的分布式框架，客户端只与master侧通信，根据实际的告警量可分多个worker处理，master侧进行汇总，master与worker之间使用socket通信，使用share memory传送告警数据。 优点：本机多进程部署，因为使用share memory，所以性能较高 缺点：工作量大，多机部署需要考虑告警

9. 分布式akka设计方案 方案描述：利用akka分布式框架， 优点：框架比较成熟，开源，很多功能在实践中进行了验证。 缺点：了解不多，资料较少，遇到问题需要

10. 客户端： 1、1000个 2、实时监控、流水窗 3、过滤器很多很复杂（按条件查看） 服务层： 1、实时分发 2、背景数据亿级 3、数据库持久化 告警源： 1、多数据源 2、3万条/s • 内存数据库：单写多读，负荷有集中点

11. 怎么做到的 主体内容，即成功要素，成功经验总结，即哪些技术或其他地方做好了才促使项目成功。 • 基于actor模型 • Actor模式是一个解决分布式计算的数学模型，其中Actor是基础 • 用来编写并行计算或分布式系统的高层次抽象，让程序员不必为多线程模式下共享锁而烦恼

12. 怎么做到的 主体内容，即成功要素，成功经验总结，即哪些技术或其他地方做好了才促使项目成功。 • Actor介绍 • 在Actor Model世界里，一切皆Actor • 每一个Actor拥有自己的状态及行为 • 所有Actor之间的交互都是通过消息来传递来实现的

13. 怎么做到的 主体内容，即成功要素，成功经验总结，即哪些技术或其他地方做好了才促使项目成功。 • Actors为你提供: • 对并发/并行程序的简单的、高级别的抽象。 • 异步、非阻塞、高性能的事件驱动编程模型。 • 非常轻量的事件驱动处理（1G内存可容纳约270万个actors）

14. 怎么做到的 主体内容，即成功要素，成功经验总结，即哪些技术或其他地方做好了才促使项目成功。 • 垂直扩展和水平扩展 • 在任务负荷增加时可以动态扩展actor（本地），从而到达垂直扩展 • 每个任务节点是透明的，可以增加远程处理单元，可以达到水平扩展

15. 怎么做到的 主体内容，即成功要素，成功经验总结，即哪些技术或其他地方做好了才促使项目成功。 • 自动恢复 • 通过监管树形结构满足多JVM下高容错性，达到高可靠性 • actor状态监控的功能配合actor自恢复实现 • Let it down, 让程序更稳定健壮

16. 怎么做到的 主体内容，即成功要素，成功经验总结，即哪些技术或其他地方做好了才促使项目成功。 • 分布存储 • master-slave框架数据分布 • Master测进行二次排序

17. 怎么做到的 主体内容，即成功要素，成功经验总结，即哪些技术或其他地方做好了才促使项目成功。 • Keepalived • 简单 • 双机热备，消除目录服务单点故障

18. 实践1.1 告警订阅服务 • 遇到的问题 • 告警量大 • 实时要求高 • 现有复杂过滤器 • 执行接近1分钟 • 执行超过1分钟 • 执行超时A • 执行超时B • 超长过滤器

19. 2013-05-29 姓名：李杰部门：技术规划部邮箱：lijie5@boco.com.cn电话：88157631

20. 实践1.1 告警订阅服务

21. 实践1.1 告警订阅服务 添加内容

22. 实践1.2 告警统计服务 • 遇到的问题 • 告警量大 • 实时要求高 • 告警统计的性能需要处理每秒一万告警 • 支持各种不同汇总维度

23. 实践1.2 告警统计服务 告警统计框图

24. 实践1.2 告警统计服务

25. And 曾经还尝试过什么但失败了/放弃了，以及未来想尝试什么? • 曾经尝试 • 基于share memory分布式框架 • 未来想尝试 • 目前存储告警相关的数据，后续把资源类数据加入做集中存储

26. 案例ROI分析 进行投入产出分析 • 实时告警处理从几百提升至几千，并可扩展至万级 • 告警量从100万扩展至500万或更多 • 基于过滤器查询、排序从几十秒、几百秒缩减至3秒内 • 为运营商省级集中、全国集中在技术上进行了保证

27. 案例启示 提炼出该案例（或项目）的哲理、方法论。 • 不要重新制造轮子 • 选型前验证的重要性 • 架构均衡的艺术 • 合适才是最好的

28. 3.技术维度 OSS场景抽象 0-OSS云化分析 • Iaas+Paas+Saas • 已完成：统一采集 • 2013年：网优/数据中心/综监工程验证 • 2014年：综资/综分/EOMS/门户 Paas层如何架构 软硬件维度 与X86虚拟化结合 2. 架构维度 系统分类 OSS云化五个维度 • 实时/非实时 • 非实时：大数据简单查询/大数据高时延复杂查询/大数据处理/大数据挖掘 • 实时：大数据低时延复杂查询/流数据处理 5. 时间维度 演进 4. 产品维度 演进 • 分产品介绍改造方案 • 技术平台类：统一采集/数据中心 • 应用系统类：3大综合/网优 • 管理/门户类：EOMS/门户

29. 1-Iaas/Paas/Saas Iaas是Paas的基础 提供快速部署、快速测试的环境 故障节点的快速退出 、恢复要求； 多节点自管理，低维护量的要求； 云计算颠覆了传统开发、测试、运维模式模式；DevOpsDevOps是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。 软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作

30. OSS云化PAAS架构 xDSP Distributed Storage platform xDPP Distributed Parallel computing platform

31. OSS云化演进-架构分层维度 务 续 ITSM OSS应用 性 施 设 P aaS Cloud Computing 础 基 件 软 操作系统 数据库 中间件 施 设 IaaS Cloud Computing 础 基 件 硬 / 网络 服务器 存储 备份 4 应用服务云： 告警相关性、告警派单、性能计算、门户服务… 4 公共服务云： GIS、拓扑、派单等服务的虚拟化… 3 4 4 数据服务云： X86低成本；MPP分布式数据及hdoop存储… 3 4 4 2 4 采集服务云： X86，流式计算，分布式，高可靠，高扩展性… 1 3 3 3 Services 2 1

32. OSS云化场景抽象

33. OSS云化场景抽象&产品线云化对应&里程碑

34. OSS云化演进-系统时间维度