共计 5907 个字符，预计需要花费 15 分钟才能阅读完成。
简介： 作为一个互联网守业公司，饿了么从初创到壮大，在挪动互联网时代，业务量和技术团队的体量经验了 10 倍增长，这其中的经验，是互联网畛域许多守业公司技术团队的一个缩影。在这里把咱们成长过程中的领会和教训记录下来。——黄晓路
作为一个互联网守业公司，饿了么从初创到壮大，在挪动互联网时代，业务量和技术团队的体量经验了 10 倍增长，这其中的经验，是互联网畛域许多守业公司技术团队的一个缩影。在这里把咱们成长过程中的领会和教训记录下来。
饿了么的技术体系，经验了以下四个阶段：
1、外围零碎 All in one 的晚期架构；
2、以零碎畛域化拆分、业务零碎和中间件等基础设施拆散为根底的全面服务化的架构；
3、随着自动化平台、容器调度体系成熟，治理从传统运维向 DevOps 转变的基础设施体系；
4、多数据中心体系根底上的 Cloud Ready 架构成型。
在这期间，业务的快速增长，大大小小的事变，组织构造的变动、交融，团队的工程师文化和技术栈背景，不同技术理念的抵触，交错在一起，相互冲击、影响着架构变迁。
第一阶段：All in one
这是饿了么技术体系晚期的样子，技术联结创始人带着一群 Geek，从 0 到 1，搭建了最早的技术体系，撑持了百万级的单量。
这个阶段，业务一路狂奔，技术拼命追赶业务，唯快不破。
技术栈以 Python 为主，兼有局部 PHP 的零碎，单机多利用的混布模式，利用公布、零碎运维基本上是开发工程师敲命令行实现。外围的业务零碎，商户、用户、交易都共享一个 codebase，建设在一个名为 zeus 的零碎下。短时间内业务飞速增长，在线数据库曾经支撑不了 ETL 的需要，大数据体系、数仓开始建设。
大数据所在的上海数据中心，在线业务零碎所在的北京数据中心开始搭建，这两个数据中心见证了咱们架构的变迁，直到起初整体上云，最早的时候，技术团队 40 多人，有时候须要创始人跑到机房外面搬服务器。
零碎跟不上业务倒退速度的时候，外围零碎经验过一些间歇性宕机的难堪阶段。一些刚刚开始开辟的业务零碎，也经验了零碎刚上线就间断宕机，不得不长期加快业务的阶段。然而这个过程也有播种，很多开发工程师线上排障能力十分强，脚本玩得很溜。
这个期间的工程师常常一人身兼数职，前端、后端、开发、测试、运维部署，对业务的了解也很粗浅，甚至身兼技术和产品的角色。
播种和教训——文化的重要性
晚期饿了么有一个显明的特点，就是大家都十分有担当，凋谢且容纳。推卸、逃避责任的事件很少产生。尽管过后很多事变回过头来看比较严重，然而，组织对技术人员成长中的谬误也绝对容纳。整个团队比拟扁平，上下级之间的技术争执是常有的事件，然而都能就技术论技术。
饿了么的工程师文化氛围还是挺强烈的：工程师想着服务器的资源利用率能不能再压迫一下；在决定大规模应用 Redis 之前，会去读 Redis 的源码；很多计划，都是找个吧台和白板疾速探讨，疾速达成共识，落地上线。可能也是这个气氛，吸引到很多雷同滋味的人，造成了技术团队的文化。技术团队创始人最后造成的文化能连续下来，是这个团队从最后的几十人倒退到上千人，还保有凝聚力和执行力的根底。
第二阶段：拆迁和基建
技术零碎架构影响了业务交付效率，那么就须要重构甚至重建零碎；如果是组织构造的不合理，妨碍了零碎架构的迭代，成为业务倒退瓶颈，那么就须要调整组织构造。
打个比方，如果说业务零碎是赛车，那么基础设施就是跑道。基础设施也是这个阶段咱们建设的重点，为承接未来业务快速增长打下基础。
这个阶段咱们面临几个问题：
Python 为主的技术栈，现有的工程师单兵作战能力都很强，然而过后市场上的兵源严重不足。
All in one 的零碎，各业务畛域没有划分，业务模块之间代码交织，影响到了交付效率，须要给业务疾速倒退松绑。
基础设施和业务零碎开发没有离开，身兼数职的开发工程师，在基础设施运维、中间件开发、前后端业务零碎开发各个方面，各有长短。
传统的手工上线、部署、运维、监控模式 —— SSH 到服务器上手工执行脚本，效率低下，事变产生时复原工夫长，公布后难以回滚。
成建制
随着业务量迅速增长，业务零碎日渐简单，技术团队也随之扩张，过后人才市场上 Java 工程师还是比 Python 的工程师起源多，有更大的抉择余地，因而，以 Java 为主的多个畛域开始逐渐壮大，造成了 Python 和 Java 两大技术栈体系。
大前端、挪动端、多个畛域的后端业务利用、运维、中间件、风控平安、大数据、项目管理等多个角色分工，不同角色的工程师做本人善于的事件。在这个阶段，零碎和组织造成了业务开发、运维、共享组件及中间件几个体系架构。
业务零碎
1、业务畛域划分
单体架构的零碎开始依照畛域拆分。All in one 的零碎，通过划分业务畛域，各个领域的技术骨干认领掉所负责的畛域，组织构造相应调整，才很艰巨的实现了划分。导购、搜寻举荐、营销、交易、金融、公共服务、商户商品、商户履约、客服，新建的物流运单、分流、调度等零碎，大数据数仓，逐渐辨认出本人畛域、子畛域及相应模块。在这个过程中，也有一些骨干在接手所负责畛域后，没有在第一工夫器重人力资源，导致交付能力有余，成为业务倒退的瓶颈。从技术骨干再到技术团队负责人这一转变过程中，很容易被疏忽的就是团队的人员构造。
2、零碎拆分
随着各自畛域内的需要疾速迭代，零碎也迅速收缩，相互之间的依赖、畛域边界也开始变得盘根错节。原来能够“闭环”的，当初须要交互了，甚至原来能够间接动其余畛域的代码提 PR，拜访他人的数据库，当初都不行了。从单体到畛域切分服务，扭转原有的思维形式，导致很多不适应，也走了一些弯路：导购域为了性能，本人落了一份商户商品数据缓存供商品查问，从而须要了解商户端畛域的业务，订阅这类主数据的变更，而商户端的这部分数据就没有方法收口，缓存的新鲜度保障、底层数据结构变更、零碎重构都比拟麻烦；交易域麻烦也不少，一些畛域为了不依赖交易，本人冗余了大部分的订单数据；物流履约畛域则是上游存在多份运单数据冗余，导致畛域职责没有收口，带来很多一致性问题，零碎的复杂度也随之减少，零碎交互和沟通老本也回升了。
而另一个极其，则是零碎拆得过散，频繁的相互调用依赖，把本该高内聚的零碎拆成低内聚了。订单和物流都经验了适度的异步化带来的苦楚，故障复原工夫过长，复杂性和排障成本增加。这段时间，畛域边界的一致也是一个头疼的事件。
领会和教训——康威定律、技术文化
订单履约体系外面，有一个隶属于商户域的团队，负责推单零碎，该零碎主要职责是承接商户呼叫配送，并将订单推送到物流运单核心。因为想缩小对订单零碎的依赖，以防订单零碎挂了，无奈履约，开发团队冗余了很多订单的数据，为此，要同时思考订单和运单的正向、逆向，本身的可用性，零碎也被设计得比较复杂。
在这个过程中，一旦有我的项目波及到物流和推单零碎交互，两个团队就常常产生畛域边界的一致，波及到一些从订单取数的场景，物流团队认为，“这部分逻辑我不应该了解，你们应该从上游零碎取到推给咱们”，而这个隶属于商户域的团队则认为，“这部分不是推单的畛域内的数据，而且推单零碎本人也用不到，物流须要应该本人去取”。
相似问题重复呈现，重复探讨，消耗掉大家很多工夫，而且可见的未来还会产生。链路过长也带来稳定性隐患。最终，负责订单域的团队，来负责推单零碎，订单畛域内的逻辑能够闭环，这个问题就迎刃而解了。
所以，波及到两个畛域边界的时候，一旦类似问题重复呈现，咱们可能要考虑一下康威定律。
对于争执：零碎设计阶段的强烈争执是十分正当的，充沛的讨论会大大减少计划呈现硬伤的概率，开发阶段也少受返工之苦。技术探讨围绕技术合理性，就事论事的开展，不要因为技术以外起因推卸或者权威说得算，探讨完大家能力很坦然的承受决定，最重要的是，参加的工程师都能充沛了解最终计划的利弊和取舍，落地不会有偏差，出了问题不推诿。这也是很多团队技术气氛吸引人的一个中央，文化不是口号，是日常的这些细节和实际。
经营体系
1、团队
负责软件交付的业务运维、负责底层操作系统和硬件交付的零碎运维、负责数据库的 DBA、稳定性保障团队，相继成立。
2、监控告警
集群实例的数量急剧扩张，登录到服务器上查看日志的运维模式曾经不事实，也被基于遥测的监控体系所代替。随着 7 *24 小时的 NOC 团队（故障应急响应）建设，基于 ELK 的监控体系也搭建起来，将外围指标投到了监控墙上。
领会和教训：监控告警机制的意义
互联网利用到了肯定复杂度当前，宏大的集群，尤其容器化之后，IP 动态分配，日志数量微小，日志数据繁冗而离散，监控和排障须要借助的是和卫星排障一样的思路——遥测。日志零碎要反对聚合和查问，监控须要实时收集采样各种指标、监控面板能够随时查看零碎以后健康状况、告警机制第一工夫发现零碎冒烟。
有一次呈现了一个问题，从监控面板上看一切正常，起初发现根因是一个 int32 溢出的 bug，导致下单失败，然而，为什么监控看不出来？因为代码外面把异样吞掉了，调用返回胜利，而咱们外围指标用的是下单接口的胜利调用量指标和一些异样指标。
通过要害指标的治理，咱们的监控面板关注三类外围指标：
业务指标 —— 实时关注业务整体的健康状况，从这个指标能够很直观的看到，业务的受损水平、时长和影响面，比方单量什么时候掉的、掉了多少比例、掉了多久，要害页面拜访的成功率怎么样。对于下面订单的案例而言，须要在下单胜利后打点（由负责订单落库的实现逻辑来实现），确保实在反映业务情况。须要留神的是这类指标通常波及到敏感的业务信息，因而须要做一些解决。
利用指标 —— 关注利用实时的健康状况，利用自身及间接上下游的调用量、时延、成功率、异样等。为了平安起见，应该留神敏感零碎信息不露出。特地是波及到金融、平安畛域的业务零碎。
零碎指标 —— 关注中间件、操作系统层面的实时健康状况，Network Input/Output、CPU load & Utilization、Memory Usage 等。故障产生时，这些指标通常会先后产生异样，须要关注哪个是因哪个是果，防止被误导。
当然以上还不够，监控还有一些须要关注的中央，随着业务的倒退，对咱们的监控零碎带来更多挑战，前面一个阶段，监控体系会有天翻地覆的变动。
这个事变给咱们的另一个教训就是，要害门路和非关键门路的隔离：那个 int32 溢出的 bug 是在非关键门路上触发的，过后还没有梳理进去要害门路，所以非关键门路故障影响到要害门路的事变时有发生。随着要害门路的梳理，后续服务降级的能力也才开始逐渐建设起来。
3、业务运维
业务运维团队担负起了很多业务零碎运行时环境的初始化工作，比方虚拟机、HAProxy、Nginx、Redis、RabbitMQ、MySQL 这些组件的初始化工作，容量评估工作。稳定性保障工作也是主要职责之一。这些分工让开发工程师能够更分心于业务零碎的交付，但也是一把双刃剑，这是后话了。
4、零碎运维
随着业余运维团队的建设，零碎从物理机迁徙到了虚拟机上，单机单利用（Service Instance per VM）是这个阶段的次要部署模式。硬件设施的运维，网络布局，缓缓都更业余标准起来，CMDB 也开始构建。
5、DBA/DA
数据库的经营对立收口到这个团队，负责数据库容量布局，可靠性保障，索引优化等等，交付了包含数据库监控体系在内的很多数据库经营工具产品，与此同时，他们也参加到业务零碎的数据架构设计和评估选型当中。
6、制度
故障等级定义、架构评审机制、全局我的项目机制也相继出炉。制度的建设、执行和以人为本，三件事件，素来难对立，得不到人的认可，则执行会打折，背离制度设立初衷，所以，制度也须要迭代。制度是底线，制度笼罩不到的中央靠团队文化来维持，然而，如果把文化当制度来执行，就得失相当了。
领会和教训——架构师到底要做什么？
架构师是一个角色，而不是职级。这个角色的职责蕴含但不仅仅限于以下方面：
1、业务零碎的技术方案设计和迭代布局
2、非性能需要的定义和方案设计、技术选型
3、现有架构的治理、畛域边界的划分、设计准则与事实（技术债）的取舍和均衡
4、架构将来的演进
然而，如果不够深刻，以上很难落地。从事前设计，到事中交付阶段的跟进，预先线上零碎经营及反馈、继续的优化迭代，都须要架构师充沛主导或者参加。
麻利开发，设计是很容易被疏忽掉的一环，制度上，咱们通过组织由运维、中间件、业务开发、数据库、平安风控各畛域的架构师组成的评审会议，在算力和基础设施资源申请通过前，审核评估设计方案。
实际上，这个上线前的“事先预防”也还是有局限性，因为这个时候设计方案曾经进去了，尽管设计文档评审前曾经提前提交，然而没有可能参加到整个生命周期，深刻水平无限，只能做到兜底。更好的机制是每个团队都有架构师的角色，在设计过程中充沛参加，这才是真正的“事先”。
所以，很长一段时间，跨畛域的重点项目或者整个技术核心的我的项目，架构师才会主导或者绝对深刻的染指，而日常迭代，在设计方案、畛域边界各方有重大一致的时候，架构师往往是被动的卷入，变成居委会大妈的角色。笼罩的畛域太广，架构师这个时候成为了瓶颈。而业务零碎的架构恰好是由日常的迭代逐渐构建而成。起初全局架构组成立，架构师才真正开始分畛域深刻到更多业务的日常交付当中：
设计方案的负责人，作为 Owner，为计划负责，并跟进交付，有势力有任务；
构建影响力。除了日常和开发工程师一起并肩交付，没有捷径，这个须要比拟长的工夫和我的项目的积攒，很难欲速不达，这个过程中如果失去一线工程师和开发经理的认可，影响力就会逐步造成，有更强的推动力，反之，则会逐渐丢失影响力。架构师如果没有影响力，所有无从谈起。因为组织上，架构师不肯定在一线开发工程师或者开发经理的汇报线上。中立主观的态度，凋谢的心智，也是构建影响力的要害。影响力是架构师 Leadership 的体现。
稳定性的保障，永远是架构师的外围关注点之一，稳定性指标是架构师必须要背负的。其中包含交付品质、可用性、弹性、零碎容量等等，不深刻到具体畛域，很难去提供保障。为此，架构师须要有调动资源保障稳定性的势力。
技术文化的影响，架构布局的贯彻，除了惯例的宣讲、分享以外，更为重要的是日常我的项目交付、技术探讨过程中的耳濡目染。设计思维、设计准则、技术文化认同，这些不是说教能造成的，是在一个个我的项目迭代、一次次线上排障、一场场事变复盘会中达到共识的。
在以上几点的根底上，才可能在全局上担负起架构的职责，推动架构的演进。敬请期待下周内容：饿了么全面服务化的架构实现和挑战；容器化实际与 DevOps 转变等。
作者：黄晓路（花名：脉坤），2015 年 10 月退出饿了么，负责全局架构的工作。
