读书笔记——《尽在双11》


作者: 康凯森

日期: 2017-08-20

分类: 笔记


1 技术和业务的关系

技术和业务的关系类似经济基础和上层建筑的关系。我们都知道经济基础决定上层建筑,上层建筑又反作用于经济基础。相应的,技术的演进是伴随解决实际业务的问题和痛点而发展和进化的,但是当一项技术足够成熟,它不仅不可以保证原有业务的稳定快速发展,而且可以产生技术红利,让其他业务直接享受这个技术的成果。

其中,规模和场景是驱动技术发展的关键要素

首先,很多问题在业务规模很小时是不会暴露出来的,以双11为例,如果双11只有几十万,几百万用户,那么阿里压根不用进行一次有一次的架构改造,普通的技术架构足以应付;

以Hadoop生态圈的众多系统为例,当你搞个几台机器玩个Demo时,你会发现HDFS,MapReduce,Yarn,HBase,Spark等系统都十分稳定和高效,但是当集群达到上千,上万台机器时,当用户有千奇百怪的用法时,你会发现这些系统各种Bug层出不穷,各种性能问题,各种扩展性问题也会随之而来;

以我最熟悉的Kylin为例,当我们的用户很少时,查询性能溜得飞起,但是现在机器负载越来越高,用户的用法越来越多,各种性能问题也随之而来。

其次,就场景而言,不同的业务特点和业务需求也会带来不一样的技术挑战,还是以Kylin为例,当初精确去重就是我们业务方的强需求,我们完全是在业务的强烈需求下完成了这个技术挑战。

那么,技术又是如何业务发展的呢

还是以OLAP系统为例,在2015年初的时候,我们公司有强烈的OLAP需求,但是我们数据平台却没有一款足够好的OLAP系统。于是我们在明确了公司主要业务线的真实需求后,对业界主流OLAP系统进行了广泛调研,最终选择了Kylin(离线)和Druid(实时),并根据我们公司真实的业务需求,对Kylin进行了大量的深度改进,如今已经在公司内部广泛使用。

如今,当我们已经有了足够成熟的OLAP解决方案后,当新的业务有OLAP需求时,我们就可以快速帮助他们解决问题,加速业务的发展。

2 系统的发展之路

在《尽在双11》这本书中,我们可以看到阿里的许多系统都是从无到有,逐渐平台化,某些最终迈向了商业化。我们来简单看下一个系统的发展基本过程和必须要解决的问题。

  1. 某些业务产生了强烈的需求
  2. 针对特定的需求实现解决方案,改造或者研发相应的系统
  3. 系统逐渐高效,稳定
  4. 系统向全公司推广,开始平台化,让系统更加易用
  5. 系统的高效性和稳定性更上一层楼,开始提供SLA
  6. 系统足够高效,稳定,易用,开始产品化
  7. 系统走出公司,进行商业化。

在系统的发展过程中,我们必须解决以下问题:

  1. 系统的安全保障
  2. 系统的权限管理
  3. 系统的成本计算
  4. 系统的自动化运维
  5. 系统的快速故障恢复
  6. 系统的智能化
  7. 系统的云化

3 技术架构演进

五彩石

  1. 抽取公共元素,沉淀共享服务,形成中间件。 其实就是Don't repeat yourself 原则,一个模块总有公共通用的部分,一个系统总有common模块,一个公司总有一个中间件或者技术工程部门,一个国家总有一些公共基础设施或者部门。
  2. 项目分三期实施。 大型项目总需要有阶段目标和成果
  3. 两个大型独立系统的整合一般都涉及到数据的归一化和各种标准的统一
  4. 当初阿里根据数据统计决定下线团购模式,但是之后我们都知道团购火了,阿里又上线了聚划算业务。这说明单纯依靠数据来决定业务也并不一定完全靠谱,我们还需要注重用户需求领域内模式的不断创新,包括商业的,技术的。 这也说明了一个好的想法,项目要想真正成功是需要相应的时势,环境,市场,技术,用户的。这让我想起了当年的中国首富陈天桥在20世纪初就搞的IPTV,是想要实现三网融合的一个东西,当年这个东西败就败在有点太超前了,这个东西是最近几年才真正商业化起来。这个故事有兴趣可以参考 一代首富 因何退隐江湖?陈天桥死于“太创新”

异地多活

  1. 异地多活是每个大型互联网公司发展的必经之路,用以解决规模伸缩能力和灾备能力。
  2. 单元化需要做到以下两点:用户流量可以随单元增加而随机分配;每个单元具备独立性。 每个单元可以认为是一个缩小规模的,包含从接入网关、应用服务到数据存储的全功能系统。每个单元具有以下特性:自包含性;松耦合性;故障独立性:一个单元的故障不会传播到其他单元;容灾性:单元之间相互备份。
  3. 中心节点保证一致性。
  4. "看到未来的能力" 对于有序的架构迭代而要越来越重要。其实前瞻性和把握时代趋势的能力对于个人,企业和国家都很重要。

混合云

  1. 云化是解决成本问题的必经之路。
  2. Docker化意味着不管在何种业务环境下,都可以简单地通过获取镜像来构建和更新整个应用环境。

OceanBase

  1. OceanBase是2010年6月立项,至今已经7年。说明一个大型的系统要变得稳定,高效,易用,不论理论基础和架构设计多么优秀,都需要大量的人力和时间去不断优化迭代,更需要足够的业务场景进行实战检验。
  2. 实现一个基本可用的分布式数据库至少需要3年,然而在互联网公司,一个项目3年没有产出基本意味着终结。所以我们在进行大型项目时,一定要小布快跑,多轮迭代,一开始着眼于核心部分,在稳定,高效,易用中应该更偏向于高效和稳定,并且在一开始对某些难度较高的部分进行简化,加速进度。
  3. OceanBase通过分布式选举协议来解决强一致性问题,其实这也是业界的普遍解法。
  4. OceanBase的分区副本通过Paxos选举协议来进行日志同步,跨分区事务通过两阶段提交协议实现,这也是业界的常见解法。

手机淘宝

  1. 异步调用和延迟加载是常用的性能优化手段。
  2. 用热补丁的方式修复线上问题。
  3. 容器化(web中的容器),组件化,插件化。

蚂蚁技术架构演进

  1. 金融系统的关键目标:高可用:4个9以上;安全;性能;成本:灵活的资源调度与按需伸缩能力是降低成本的关键;资金安全;数据质量。

4 大型系统的稳定保障

容量规划

  1. 阿里容量规划发展的4个阶段:

    1. 人工估算
    2. 线下性能压测估算
    3. 线上压测估算
    4. 全链路压测估算
  2. 估算公式: 预估业务量级 / 单机能力 = 最小机器数。 采购机器数 = 最小机器数 + Buffer。预估业务量级通过BI分析+预测算法可以拿到比较准确的值;单机能力的获取主要是通过线下的性能测试。

  3. 线上压测评估容量:将单机能力获取直接搬到线上。 对整个压测流程进行精准的控制和实时的监控,对异常情况进行完备的容灾。历经线上模拟压力测试,线上流量复制压力测试,线上引流压力测试(把分布式的流量比较集中地调用到某一台机器上)3个阶段。
  4. 全链路压测彻底解决容量规划问题。
  5. 容量规划的本质是资源管理

全链路压测

全链路压测的目的是通过模拟双11的系统压力来发现问题,全方位校验业务的稳定性。全链路压测主要包含以下部分:

  1. 业务改造升级支持全链路压测。
  2. 数据构造:足够量级的数据和正确的数据模型。
  3. 数据隔离:在所有写数据的地方对压测流量进行识别,如果是压测流量的写,就写到隔离的位置,包括存储、缓存、搜索引擎等。
  4. 平台化:压测能力开放,让业务方可以自主压测。
  5. 日常化:让压测可以在白天进行。

全链路功能

全链路功能的目的是模拟双11当天的用户行为,来保证系统的功能和表现符合预期。全链路功能的架构和技术包括以下部分:

  1. 数据同步系统:全链路功能使用的影子数据必须和线上一一对应。
  2. 模型系统:抽象出买家和商品两个主要维度,基于数据特征向量表分别过滤商品和用户,然后随机组合下单。
  3. 隔离系统:流量隔离; 时间控制:直接改JDK。
  4. 构造执行系统。
  5. 分析系统:错误码分析;审计分析;Response分析。

自动化备战

可以自动化的就不要人工来搞。包括以下部分:

  1. 流量和容量评估
  2. 全链路压测系统
  3. 全局资源调度系统
  4. 弹性伸缩
  5. 预案平台:突发情况出现时如何应对
  6. 流量调度

实时业务审计

实时监测线上系统产生的数据是否正确。

故障演练

任何技术设施、系统、人、流程都可能出问题。减少故障的最好方式就是让故障在可控的前提下经常性地复现。故障演练的目的就是以场景话的方式沉淀,以可控成本在线上模拟故障。

强弱依赖治理:依赖模型包括关系、流量、强弱等因素。合理且清晰的依赖关系数据可以被利用到系统调用优化、故障根源查找、系统降级、依赖容量、依赖告警、代码影响范围、系统发布顺序等诸多场景。

故障的理解:

  1. 问题:凡是不符合预期的表现都可以称为问题,问题不等于故障。
  2. 故障:只有带来一定业务影响、满足一定标准的问题才会被称之为故障
  3. 故障的发生是独特的:没有两个完全相同的故障。
  4. 故障是可以被抽象的:任何一个故障的发生原因都是确定的,可以被归纳到一种或者几种故障组合

系统自我保护

系统自我保护是稳定性的最后一道屏障,主要包含以下部分:限流、自动降级、流量调度、负载保护和预案。

  1. 限流:令牌桶算法。
  2. 自动降级:"弃车保帅"。
  3. 流量调度:根据机器的实时服务能力来分配机器的实时流量。
  4. 负载保护。
  5. 预案。

5 技术拓展商业边界

  1. 数据化、算法、产品构成了智能商业的3个基石。更重要的是要形成一个反馈闭环: 数据既是高速流动的介质,又持续增值,算法既是推动反馈闭环运转的引擎,又持续优化,产品既是反馈闭环的载体,又持续改进功能。
  2. 把商家竞争意识、消费者行为、平台意志结合到一起,打造成一个生态闭环。

DorisDB —— 新一代极速 MPP 分析型数据库

DorisDB 是由 Apache Doris 核心研发团队打造的新一代企业级 OLAP 数据库,继承了 Apache Doris 项目十多年研发成果,以及数千台服务器稳定运行经验,并在此基础上,对传统 MPP 数据库进行了开创性的革新。 DorisDB 重新定义了 MPP 分布式架构,集群可扩展至数百节点,支持 PB 级数据规模,是当前唯一可以在大数据规模下进行在线弹性扩展的企业级分析型数据库。

DorisDB 打造了全新的向量化执行引擎,查询性能相比 Apache Doris 整体有5到10倍的提升,导入性能相比 Apache Doris 整体有10到30倍的提升。

如果你想和我们一起打造一款世界第一的企业级 OLAP 数据库,欢迎发送简历到 kangkaisen#dorisdb.com

如果你希望了解 DorisDB 相关问题,欢迎添加下面的微信号:

评论