关键词：
网站在刚开始的时候大概只是一个想法：一个产业的模型，快速地将它产生出来。“快”是第一位的，不需要花太多精力在架构设计上。在网站进入扩张期才需要对架构投入更多的精力来承载网站在爆发时的流量。
饿了么成立已经8年，现在日订单量突破900万，我们也有了较为完善的网站架构。
一、网站基础架构
初期，我们使用了能够更容易拓展SOA的框架。我们用SOA的框架解决两件事情：
1. 分工协作
网站初期，程序员可能就1~5个，那时大家忙同一个事情就可以了。彼此之间的工作都互相了解，往往是通过“吼”的方式就把问题解决了。
但随着人员的增加，这种方式显然是不行的，不可能一个人更新了代码再把其他人的所有代码重新上线一遍吧？于是就要考虑分工协作的问题。
2. 快速扩展
以前订单量可能从1k到1w，虽然增长了10倍，但是总量并不是很高，对于一个网站的压力来说，也不是那么大。真正到了订单量从10w到100w，从100w到 200w的时候，可能数字上只是扩大了10倍，但对整个网站的架构上来说却是一个巨大的挑战。
我们的背景就是2014年的100万突破到现在的900万，技术团队由刚开始的30多个人，到现在已经是超过900人的团队。这时候分工协作是个巨大的挑战。服务的分分合合，团队的分分合合，这都需要一套框架体系来支撑，这也是SOA框架的一个作用。
看一下我们的现状，中间是我们整个架构的体系，右侧是和服务化相关的一些基础，包括基础的组件或者服务。
先说语言，我们原来的网站是在PHP上的，后来慢慢转型。
创始人都是大学生创业，那么理所当然Python是一个很好的首选。到现在 Python也是很好的选择，但是我们为什么要扩展到Java和Go呢？
Python很多人都会写，但是真正能把它做得很好的人并不多。随着业务的发展，需要更多的开发人员。考虑到Java成熟的生态环境，以及新兴的Go生态，我们最终选择了Python、Java、Go多语言共存的一个生态。
WebAPI主要做一些HTTPS卸载、限流，还有安全校验等一些通用的和业务逻辑无关的操作。
Service Orchestrator是服务编排层，通过配置的方式实现内外网的协议转换、服务的聚合裁剪。
架构图右边是一些围绕这些服务化框架的辅助系统，比如说用于定期执行一个任务的Job系统。我们有将近快1000个服务，这些系统怎么监控？所以必须有一套监控系统。刚开始只有30多个人时，我们更擅长的是跑到机器上去搜一下Log，但到了900多人时，你不可能都到机器上去搜一遍Log，需要有个集中式的日志系统。其它的系统这里就不一一赘述了。
罗马不是一天建成的，基础架构是个演进的过程。我们精力有限，那先做什么呢？
二、服务拆分
当网站变大了，原来的架构跟不上发展的节奏了。我们要做的第一件事情就是：
把大Repo拆成一个小Repo，把大服务拆成小服务，把我们的集中基础服务，拆分到不同的物理机器上去。
光是服务拆分用了一年多的时间才做完，这是一个比较漫长的过程。
这个过程中，首先要对API做一个很好的定义。因为一旦你的API上线之后，再做一些修改的成本是相当大的。会有很多人依赖于你的API，很多时候你也并不知道有谁依赖于你的API，这是一个很大的问题。
然后再把一些基础服务抽象出来。很多原来的服务其实是耦合在原来的业务代码里面的。比如说支付业务，业务很单一时，紧耦合的代码没有关系，但是扩展出的越来越多的业务都需要支付服务时，你每一个业务（比如说支付的功能）都要去做一个吗？所以我们要把这些基础服务抽离出来，比如支付服务、短信服务、推送服务等。
拆服务看似很简单、没什么价值，但这恰恰是我们刚开始就要做的事情。其实在这个时期，前面所有的那些架构都可以往后拖，因为不做架构调整其实不会死人，但是拆服务你不做的话，真的会死人。
服务拆分必定是一个漫长的过程，可这实际是一个很痛苦的过程，也需要很多配套系统的系统工程。
三、发布系统
发布是最大的不稳定因素。很多公司对发布的时间窗口有严格的限定，比如说：
每周只有两天可以发布；
周末是绝对不可以发布的；
业务的高峰期绝对不允许发布；
等等……
我们发现，发布的最大问题在于发布上去之后没有简单可执行的回退操作。回退操作到底是谁来执行，是发布人员就可以执行，还是需要专人来执行？如果是发布人员的话，发布人员并非24小时在线工作，出了问题找不到人怎么办？如果是有专人来执行回退，而又没有简单、统一的回退操作，那这个人需要熟悉发布人员的代码，这基本上不可行。
所以我们就需要有发布系统，发布系统定义了统一的回退操作，所有服务必须遵循发布系统的定义回退操作。
在饿了么对接发布系统是对所有人的强制要求，所有的系统必须全部接入发布系统。发布系统的框架很重要，这个东西其实对于公司是很重要的一件事情，需要放到第一优先级的队列里面去考虑。
四、服务框架
紧接着就是饿了么的服务框架，把一个大的Repo拆分成一个小的Repo，把一个大的服务拆成一个小的服务，让我们的服务尽量独立出去，这需要一套分布式服务框架来支撑。
分布式服务框架包含的服务注册、发现、负载均衡、路由、流控、熔断、降级等功能，这里就不一一展开了。前面已经提及，饿了么是多语言的生态，有 Python的，也有Java的，我们的服务化框架对应也是多语言的。这对我们后来一些中间件的选型是有影响的，比如说DAL层。
五、DAL数据访问层
当业务量越来越大的时候，数据库会变成一个瓶颈。
前期可以通过提升硬件的方式来提升数据库的性能。比如：
升级到一个有更多CPU的机器；
把硬盘改成 SSD 的或者更高级一点的。
但硬件提升终归是有一个容量限制的。而且很多做业务的小伙伴，写代码的时候都直接操作数据库，发生过很多次服务一上线数据库就被打爆的情形。数据库被打爆掉了之后，除非等待数据库恢复，没有任何其它机会可以恢复业务。
如果数据库里面数据是正常的，业务其实都可以补偿出来。所以我们做DAL服务层的时候，第一件事情是限流，其它的东西可以放一放。然后做连接复用，我们Python框架用的多进程单线程加协程的模型。
多进程之间其实是不可以共享一个连接的。比如：一台机器上部署了10个 Python进程，每个进程10个数据库连接。再扩展到10台机器上，就有1000个数据库连接。对数据库来说，连接是一个很昂贵的东西，我们DAL层要做一个连接复用。
这个连接复用讲的不是服务本身的连接复用，而是说DAL层上的连接复用，就是服务有1000个连接到DAL层，经过连接复用后对数据库可能只是保持着十几个连接。一旦发现某个数据库请求是一个事务的话，那么DAL就帮你保留这个连接的对应关系。当这个事务结束之后，就把数据库的连接，放回到共用池里面去，供其他人使用。
然后做冒烟和熔断。数据库也可以熔断的。当数据库发生冒烟时，我们会杀掉一些数据库的请求，保证数据库不至于崩溃。
六、服务治理
服务框架之后，涉及服务治理的问题。服务治理其实是一个很大的概念。首先是埋点，你要埋很多的监控点。
比如有一个请求，请求成功了或者失败了，请求的响应时间是多少，把所有的监控指标放到监控系统上面去。我们有一个很大的监控屏幕，上面有很多的监控指标。有专门小组72小时去盯着这个屏幕，如果有任何曲线波动了，就找人去解决。另外是报警系统，一个监控屏幕展示的东西总是有限的，只能放那些很重要的关键指标。这个时候就需要有报警系统。
罗马不是一天建成的，基础架构更是一个演进的过程。我们的资源和时间总是有限的，作为架构师和 CTO 来说，如何在这种有限的资源下，产出更重要的东西？
我们做了很多系统，觉得自己做得很不错了，但实则不是，我感觉我们又回到了石器时代，因为问题越来越多，需求也越来越多，总感觉你的系统里还缺点什么东西，想做的功能也一大堆。
比如对于流控系统，现在我们还是需要用户去配一个并发数，那么这个并发数，是不是根本不需要用户去配？是不是可以基于我们服务本身的一个状态自动去控制并发数？
然后是升级方式，SDK升级是个很痛苦的事情。比如说我们服务框架2.0发布的时候是去年12月份，到现在还有人用的是1.0。是不是可以做到SDK的无损感升级，我们自己来控制升级的时间和节奏。
还有，我们现在的监控只支持同一个服务上的汇聚，是不分集群、不分机器的，那是不是以后的指标可以分集群、分机器？举一个最简单的例子，比如一个服务上有10台机器，那么可能只是某一个机器上出了问题，但它所有的指标都会平均分摊到其它的9台机器上去。你只是看到了整个服务延时增加了，但有可能只是某一台机器拖慢了整个服务集群。但我们现在还做不到更多维度的监控。
还有智能化的报警，这个报警，就是要快、全、准，我们现在做到更快了，做到更全了，怎么才能做到更准？每天的报警量高峰时间一分钟一千多个报警发出去。所有的一千报警都是有用的吗？报警多了之后，就相当于没有报警。大家都疲劳了，就不去看了。我怎么能够把这个报警更准确地区分出来？还有更智能化的链路分析？以后是不是我们的监控不要放监控指标，而是放链路分析，这样就能够很清晰地知道，这个问题对应的是哪一个结点上出了问题。
这些问题涉及我们做事的一个原则：东西够用就好，但是要能够未雨绸缪，做一定的超前规划。
本文来自 《CTO说》
本文出自 “51CTO博客开发” 博客，谢绝转载！
饿了么移动app的架构演进
...不断接受挑战的过程中，成就了今天的移动互联网时代。饿了么移动APP就是这样一个挑战，多用户量、多业务量，在接受着更多更挑剔用户的同时，默默地、不断地演进着移动端的 查看详情
饿了么：业务井喷时订单系统架构的演进
摘要：饿了么是一家创业公司，业务发展非常快，可能准备不是很充分，比如说监控、日志、告警、框架、消息、数据库，很多基础设施还在建设之中。在这个过程中出现一些问题是在所难免的，对系统的要求不是不能挂、不能... 查看详情
极速发展的饿了么订单系统架构演进--转
...请到北京站官网查询。先自我介绍一下，我于2014年加入饿了么，那时正是饿了么飞速发展的起始点。 查看详情
饿了么分布式服务治理及优化经验（含ppt）
饿了么分布式服务治理及优化经验（含PPT）导读：高可用架构7月30日在上海举办了『互联网架构的基石』专题沙龙，进行了闭门私董会研讨及对外开放的四个专题的演讲，期望能促进业界对互联网基础架构的建设及发展，本文是... 查看详情
vue饿了么的技术点
一：项目目录设计。1：制作矢量图片的图标字体。打开icomoon.io网站,点击importicons，上传自己的svg图片，制作自己的图片，上传之后点击generatefont图标，下载然后把其中的font文件夹复制，style.css复制到style文件夹，修改为icom.styl... 查看详情
各大互联网公司架构演进之路汇总
各大互联网公司架构演进之路汇总点击上方“Hollis”关注我，精彩内容第一时间呈现。全文字数：800阅读时间：2分钟大型网站架构演化历程大型网站架构技术一览支付宝和蚂蚁花呗的技术架构及实践支付宝的高可用与容灾架构... 查看详情
饿了么的萧瑟之秋
650)this.width=650;"src="http://zhuyi.blog.techweb.com.cn/files/2016/09/271828008142082724.jpg"title="271828008142082724"width="400"height="240"class="aligncentersize-fullwp-image-1867"style="border:0 查看详情
经典文摘：饿了么的pwa升级实践（结合vue.js）
...Vue.js官方推特第一次公开到现在，我们就一直在进行着将饿了么移动端网站升级为 ProgressiveWebApp 的工作。直到近日在GoogleI/O2017上登台亮相，才终于算告一段落。我们非常荣幸能够发布全世界第一个专门面向国内用户的PWA... 查看详情
饿了么基于vue2.0的通用组件开发之路（分享会记录）
Element：一套通用组件库的开发之路Element是由饿了么UED设计、饿了么大前端开发的一套基于Vue2.0的桌面端组件库。今天我们要分享的就是开发Element的一些心得。官网：http://element.eleme.io/#/github：https://github.com/ElemeFE/element ... 查看详情
基于vue来开发一个仿饿了么的外卖商城(代码片段)
一、准备工作1.大前提：已安装好node、npm、vue、vue-cli、stylus（此项目使用stylus来编译）2.开发软件：GoogleChrome（建议安装插件vue-devtools，方便调试），webstorm/sublimeText/VSCode（推荐使用webstorm，sublime和VSCode需要安装相应的插件）3.... 查看详情
基于vue来开发一个仿饿了么的外卖商城(代码片段)
一、抽出头部作为一个组件，在底部导航的时候可以相应的显示不同的标题技术点：使用slot进行组件间的通信；父组件给子组件传值（子组件里面通过props接收父组件传过来的数据）查看链接：https://blog.csdn.net/sinat_17775997/article/... 查看详情
今日头条架构演进之路——高压下的架构演进专题（含ppt）
今日头条架构演进之路——高压下的架构演进专题（含PPT）导读：高可用架构在6月25日举办了『高压下的架构演进』专题沙龙，进行了闭门私董会研讨及对外开放的四个专题的演讲，期望能促进业界应对峰值方法及工具的讨论，... 查看详情
高并发大访问量架构设计演进之路归纳总结
高并发大访问量架构设计演进之路归纳总结第01：大型架构的演进之路第02（上）：分布式缓存第02（下）：分布式缓存第03：分布式消息队列第04：分布式数据存储第05：分布式服务框架第06：高性能系统架构第07：高可用系... 查看详情
阿里8年资深技术专家谈企业级互联网架构的演进之路
...、分布式消息系统(Notify/ONS)等，故对整个分布式的互联网架构比较了解。本文分享围绕阿里技术架构演进及过程中遇到的问题与企业级信息系统架构的演进展开。阿里技术架构演进及过程中遇到的问题2003年，淘宝最初的架构建... 查看详情
经典必会款！服务端高并发分布式架构演进之路
...为例子，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。2.基本概念在介绍架构之前... 查看详情
淘宝从几百到千万级并发的十四次架构演进之路！
...为例子，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。2、基本概念在介绍架构之... 查看详情
阿里饿了么？复盘马云102年商业大思维
2018年2月26日，突然传来阿里可能以95亿美元全资收购饿了么的传闻，阿里巴巴官方随后表示对“市场传言”不予置评。2016年8月，阿里巴巴和蚂蚁金服一起向饿了么投资12.5亿美元，2017年又进一步增持饿了么。2017年8月，饿了么宣... 查看详情
倪江利：魅族推荐平台的架构演进之路
摘要：魅族拥有超大规模的用户量及海量数据，魅族推荐平台实现了在海量的数据中对算法模型进行在线及离线训练，在高并发的场景下实时进行预测为用户推荐更感兴趣的信息。同时支撑多算法组合A/B测试，以供算法进行在线... 查看详情