关键词：
沈询，阿里巴巴中间件&稳定性平台资深技术专家，在淘宝工作八年间，主要负责的产品有淘宝分布式数据库（TDDL/DRDS）、分布式消息系统(Notify/ONS)等，故对整个分布式的互联网架构比较了解。本文分享围绕阿里技术架构演进及过程中遇到的问题与企业级信息系统架构的演进展开。
阿里技术架构演进及过程中遇到的问题
2003 年，淘宝最初的架构建设是采用 PHP，实践发现系统抗压能力相对薄弱。因为淘宝是一个企业级系统，所以选择了当时非常重要的企业级技术 JavaBean。之后把整个 Web 的容器、EJB 等整套体系引入淘宝，雇用有经验的工程师一起做架构。淘宝在技术方面也走过很长的路，在架构建设过程中，大家讨论最多的事情是如何划分模块。
随着技术的不断发展，到 2006 年，淘宝技术又从 EJB 过渡到 Spring，如下图：
目前，这个产品已经开源，最上层采用的是 JBoss、中间采用 Webx，之后是 Spring、OR-Mapping，底层用到是 Oracle 数据库。用 Search 做搜索引擎，是因为当时收购雅虎，把雅虎的搜索引擎挂接到淘宝。像这样采用分布式的存储方式在现在看来很常见。
当时，业务不断高速发展，一些问题随之逐渐暴露出来。这里主要分享工程维护、人员变动、数据孤岛、数据集能力不足等问题。
工程维护与人员变动
随着业务不断壮大，技术团队的工程也会越来越多，源代码加速膨胀。多个工程之间，源代码冲突严重同时因为工作没有边界导致相互协同的成本不可估量。
假设出现项目完成，核心人员离职的情况，项目维护也会成为问题，当新人入职之后，学习老代码的难度也可想而知。
数据孤岛
数据孤岛是各个公司很普遍的问题，在那个时期，天猫还叫淘宝商城，不是基于淘宝，而是完全独立的一个组。
后期因为一些原因，想要把两个体系合并，却因为各自独立的业务体系、用户 ID、数据存储格式等等差异导致操作困难。且数据本身质量不高，做统一分析也有难度。
数据库能力达到上限
当时用的是小型机+Oracle，CPU90% 以上，每年宕机最少一次。这主要是因为有大量新业务写入，两周一次的频度，不断地有新 SQL 产出。
在新的 SQL 中，如出现一个慢 SQL，就会出现宕机。当时我们用的小型机重启一次需要 20 分钟，切换到异地也是 20 分钟。
关于连接数问题，如下图：
当时后端 Oracle 的连接池有限，约 8000 个左右，一旦超过就会出现问题。因为超过数量，链接占的内存会非常大，且连接数单点风险系统很高。
阿里面对 DBA 相关问题的应对方法
综上所述，当时阿里 DBA 面临维护人员很多，团队职责不清、数据无法共享，团队各自为战、小型机数据库压力过大，连接数单点风险系统很高等问题。
好在阿里那时正处于增长期，所以这时通过招聘一些技术大牛来解决问题。
基于 EDAS 进行服务化改造
针对阿里 DBA 遇到的问题，从硅谷请来的技术人用服务化的方式试着解决。当时在中国只有用友做过服务化，且效果不是很好，没有借鉴，只能谨慎小心的自己往前走。
如下图，是阿里以服务化方式将系统专业分工的三个关键战役。
用户中心服务化
选择用户中心的第一个是做服务化，因为用户中心是最小集合，最简单清楚，还因为确实有业务需求，也是想要验证这条服务化的理念是不是正确。
服务化之前的用户中心，有六个不一样的查询方法，看起来遍历的方式差不多，但可能某个参数不同，因为数据来自不同的团队。
服务化的原则是能不改不改，能简化简化，采用的传输方式是 HTTP。然而，这样做行不通，是因为除了服务化 HTTP，其他内容没有改变，就需要布设 Load Balance。
为了保证 Load Balance 尽可能稳定，所以选择硬件 F5 来配置。把前端进入的用户流量打到 F5，额外在增加新 VIP 接口，请求通过 F5 转出去。
这里发现一个很严重的问题，就是每当用户登陆一次，出现一个节点，跳转一次流量就要增加一倍。但 F5 是很贵的设备，未来如果所有都变成服务化，用 F5 就不可行。
千岛湖项目
配置 F5 负载均衡行不通，换了另一种思路就是由集中的单点模式变成真正意义的分散模式。当时阿里把这样的方式叫软负载，做的是分散负载均衡的事情。
当做交易中心服务化时，必然要用事物相关的方式，来保证整个流程的稳定性、一致性，当时采用的是最终一致性的设计方法。之后，通过实践反复修改，优化，得到稳定的消息系统。
有了消息系统的研发经验，随后类目属性等中心也随之服务化，之所以叫千岛湖项目，是因为大家很辛苦，完成项目之后去千岛湖旅游。
五彩石项目
随着千岛湖项目完成，底层架构、中间件的稳定，之后要做的事情就是把庞大的系统全部一次性服务化。
恰逢此时，淘宝商城和淘宝需要合并，所以整个系统在那个时期进行了彻底的拆分，也就是淘宝 3.0。
之后再也没有出现 4.0，一直采用服务化的架构方式。
基于 DRDS 进行数据库分布式改造
DRDS 建设初衷是希望对 Oracle 进行数据解析，同步到 MySQL 中。当时大家觉得 Oracle 很稳定，整个系统不会丢数据，所以要把 Oracle 放在主机。
但也发现一个问题，一是小型机比较贵重需要在后端加入大量 PC 机，进行读写分离。还有就是看似稳定的 Oracle，在 Linux 环境中表现不是很好，尤其是两者还在兼容上存在很多问题。
如下，是传统数据库向分布式数据库的转化图：
最终选择用分布式的 MySQL 架构来解决问题，借鉴 Facebook 技术团队开发的开源项目 Flashcache 机制，为 MySQL 加速，完成整个业务的部署。在 Linux 环境下，MySQL 比 Oracle 更加稳定、运维成本也相对较低。
如上是做服务化中心带来的好处，显而易见。经过一段时间的改造之后，技术架构发生了很大变化，如下图：
在整个技术架构的最底层是 EDAS、DRDS、ONS 等组成的基础应用架构。电商、物流、移动IM、地理信息、医疗等都有自己的能力且都把能力进行开放，形成了IT共享业务架构层，用来支撑上层的业务。一旦业务需要合作，下层的技术可以快速响应。
例如，淘宝和滴滴从谈合作到项目顺利完成，只用了不到五天的时间。当时是一个内网打车软件，用这个软件打车可实现通过公司账户去叫车，省去贴发票环节。
这件事情，真正的凸显出，技术可以帮助业务解决一些问题。虽然淘宝可能再也没有 4.0 版本，但现在每套应用系统都是为了未来而准备。
企业级信息系统架构的演进
通过对阿里技术发展历程的总结，我们发现这些经过实践得出来的技术架构对一部分企业可以起到借鉴的作用。所以规划成一个产品——企业级信息系统。
云计算时代，企业信息化演进不仅仅是把 IT 系统搬到云上，而是让业务与信息系统深度融合，改变业务运营和创新模式。
如下图，是企业级信息系统的演进过程：
把业务云化，从虚拟机模式转变成基于分布式的互联网架构进行重构，重构后给企业带来的主要的价值是原来的一些效率问题得以解决。所以说，互联网架构平台是企业云上演进的使能平台。
如下图是企业级互联网架构平台对应的下层架构：
最底层是基础框架，主要涉及 EDAS、MQ 和 DRDS 三大产品：
EDAS 主要职责是业务应用的编写和发布。
MQ 是在异步解耦的过程中，用来做消息的编辑和保证事物的一致性。
有大量的用户和数据后，由 DRDS 负责分散到各个应用中去。
三个产品加起来，从上到下，很好地支撑业务的编写、相互通信以及下层数据的建设。
CSB（能力开放平台）的主要职责是将阿里的 negligible 对外开放运营、保证内部数据的安全性和开放性，同时和现有的系统打通，进入到系统中去。云化业务的能力部分，是和客户一起设计构建。整套系统到最后的核心关键点是成本、稳定和效率。阿里在业务高速增长的这十几年实践中，积累了很多这三方面的经验。希望这些经验可以帮助一些企业少走弯路。
如下图，是企业级互联网架构的关键特征：
随着机器数量的增加，性能一定是线性增加、可靠性成指数型增长、运营成本要保持对数级上升。这些才是真正互联网架构的关键特征，如果系统不能很好的解决这些问题，它会是一个无法向上扩展的系统，那么就无法满足未来用户的增长需要。
写在最后
为什么会有这些互联网系统？为什么会有这些互联网架构的特征？很简单，因为阿里的软件和服务最终是为用户服务的，当用户成指数级增长时，系统没有很好的扩展性，就一定会死。
什么是企业级互联网？就是如果光凭借互联网模式往前走，成本、研发效率等都会成为问题。基于过往经验，重新认知思考后，希望通过软件的方式让互联网业务写的更容易，更能够贴合企业高速增长的需求。
以上内容根据王晶昱老师在 WOTA2017 “云服务架构”专场的演讲内容整理。
2008 年加入淘宝后在中间件和稳定性平台工作至今。目前负责阿里分布式数据库，之前叫 TDDL，现在运用到阿里云上改名为 DRDS、阿里的分布式消息服务(Notify/MetaQ)，以及阿里企业级互联网架构平台的新产品研发工作。
本文出自 “12562290” 博客，请务必保留此出处http://12572290.blog.51cto.com/12562290/1953308
各大互联网公司架构演进之路汇总
各大互联网公司架构演进之路汇总点击上方“Hollis”关注我，精彩内容第一时间呈现。全文字数：800阅读时间：2分钟大型网站架构演化历程大型网站架构技术一览支付宝和蚂蚁花呗的技术架构及实践支付宝的高可用与容灾架构... 查看详情
阿里云文件存储的高性能架构演进之路
...术论坛，一起探讨解决数据中心所面临的挑战。论坛上，阿里云分布式存储团队高级技术专家田磊磊进行了《阿里云文件存储的高性能架构演进之路》的报告。10月27日下午，2018中国计算机大会上举办了主题“数据中心计算”的... 查看详情
架构的演进，阿里资深java工程师表述架构的腐化之谜
前言新技术层出不穷。过去十年时间里，我们经历了许多激动人心的新技术，包括那些新的框架、语言、平台、编程模型等等。这些新技术极大地改善了开发人员的工作环境，缩短了产品和项目的面世时间。然而作为在软件行业... 查看详情
斗鱼api网关演进之路(代码片段)
...拍云，举办OpenResty×OpenTalk全国巡回沙龙武汉站，斗鱼资深工程师张壮壮在活动上做了《斗鱼API网关演进之路》的分享。OpenRestyxOpenTalk全国巡回沙龙是由OpenResty社区、又拍云发起，邀请业内资深的OpenResty技术专家，分享OpenResty... 查看详情
云湖共生-释放企业数据价值
摘要：2021云栖大会云原生企业级数据湖专场，阿里云智能资深技术专家、对象存储OSS负责人罗庆超为我们带来《云湖共生-释放企业数据价值》的分享。本文主要从数据湖存储演进之路、数据湖存储3.0进化亮点等方面分享... 查看详情
首届阿里巴巴在线技术峰会，9位大v演讲整理！
...之路、企业大数据平台仓库架构建设思路、阿里聚安全在互联网业务中的创新实践，9位专家的PDF和文 查看详情
高并发大访问量架构设计演进之路归纳总结
...色的编程能力：优秀的代码深刻领悟主流技术产品模式；互联网架构的关键技术：缓存，异步，分布互联网架构的核心要素：性能，可用，安全架构设计方案：系统，框架，数据库架构师的成长：搞定问题的攻略大型分布式架构... 查看详情
前沿分享｜阿里云资深技术专家魏闯先：analyticdbpostgresql年度新版本发布
...-云原生数据仓库AnalyticDB技术与实践峰会分论坛中，阿里云资深技术专家魏闯先关于“AnalyticDBPostgreSQL年度新版本发布”的分享。本篇内容将通过三个部分来介绍AnalyticDB PG年度新版本发布。一、AnalyticDB PG云原生架构二、云... 查看详情
架构杂谈——也谈互联网系统架构演进
Tips：说到互联网系统架构，随便网上一搜都有大量的相关文章/书籍，而这些，得益于过去几年互联网行业的快速发展与繁荣，在今天看来，这些技术/解决方案似乎早已不是什么新鲜的东西了，但是... 查看详情
架构杂谈——也谈互联网系统架构演进
Tips：说到互联网系统架构，随便网上一搜都有大量的相关文章/书籍，而这些，得益于过去几年互联网行业的快速发展与繁荣，在今天看来，这些技术/解决方案似乎早已不是什么新鲜的东西了，但是... 查看详情
阿里云杨敬宇：边缘计算行业通识与阿里云ens的技术演进之路
...前算力分布形态发生根本变化回顾历史，自从1994年接入互联网，已经有20多年的时间，从应用场景看，终端从PC时代走到了移动时代，也包括电视、摄像 查看详情
日均数十亿访问量，解读个推api网关高能演进
...邀参与SegmentFaultD-Day线上技术直播活动，与来自头部互联网企业的后端技术专家们共探“后端架构演进之路”。李白以“API网关演进之路”为主题，分享了个推基于golang进行API网关建设的实践经验和深度思考。★以下为李... 查看详情
前沿分享｜阿里云资深技术专家魏闯先：analyticdbpostgresql年度新版本发布
...#xff0c;广告等业务部门，服务于阿里云的金融、政企、互联网等各行业用户，支持快速构建新一代云化数据仓库服务。它具有以下四个特点：第一，PB级数据秒级响应。采用向量化计算以及列存储和智能索引，... 查看详情
一文看懂微服务背后的技术演进与应用实践
简介： 2021年7月2日，阿里云用户组（AUG）第一次线下活动在济南召开。阿里云云原生资深专家李国强结合自身微服务领域经验，现场跟数十家山东企业分享了云原生的代表技术之一“微服务”的演进和应用实... 查看详情
一文看懂微服务背后的技术演进与应用实践
简介：2021年7月2日，阿里云用户组（AUG）第一次线下活动在济南召开。阿里云云原生资深专家李国强结合自身微服务领域经验，现场跟数十家山东企业分享了云原生的代表技术之一“微服务”的演进和应用实... 查看详情
云原生微服务治理技术朝无代理架构的演进之路
摘要：本文基于对微服务治理技术从SOA,微服务框架，到云原生架构的历史发展总结，提出了一种新的基于Javaagent技术的新一代无代理架构的服务治理技术，并介绍了其相关的代表性开源项目Sermant。本文分享自华... 查看详情
从vmware到阿里神龙，虚拟化技术40年演进史
这几年，越来越多的企业把业务搬到云上来，阿里云顺势推出一个既兼具物理机的性能，同时又能提供虚拟机体验的产品——神龙。这款服务器的架构是怎样的？有何特别之处？在「CSDN在线峰会——阿里云核心技术... 查看详情
赵弘扬：阿里云elasticsearch技术演进之路
参考技术A导读：全文将围绕以下三方面内容介绍阿里云Elasticsearch技术。01阿里云Elasticsearch业务1.业务规模阿里云Elasticsearch业务（简称ES），从2017年至今已经服务了几千个客户，数据规模达20PB，在公共云上拥有10000+集群，10W+节... 查看详情