点击上方“朱小厮的博客”，选择“设为星标”后台回复"书"，获取后台回复“k8s”，可领取k8s资料

自创立以来的，淘宝业务发展非常迅速，几乎是每年以100%的速度在成长。创立之初，为了快速上线，抢占市场，选择了当时流行的LAMP架构，用PHP作为网站开发语言， Linux作为操作系统，Apache作为Web服务器，MySQL为数据库，用了三个月不到的时间淘宝就上线了。当时整个网站应用服务器大概10台左右，MySQL数据库采用了读写分离、一主两备的部署方式。

2004年在淘宝业务发展的推动下，我们参考电信运营商、银行等的一些企业解决方案，将LAMP架构改造为Oracle+IBM小型机的数据库架构和EMC存储方式（图2）。虽然方案成本昂贵，但性能非常好。同时，随着网站流量的增加，系统显得有些不堪重负。

图2

当时最担心的问题是网站流量如果持续增加，交易量持续增加，网站的系统架构怎么设计？如何选择数据库？如何选择缓存？如何构建业务系统？……

后来参考eBay的互联网设计架构，设计了一个Java的技术方案，并使用了非常多的Java开源产品。

例如，选择当时比较流行的JBoss，作为应用服务器；选择一个开源的IOC容器Spring，来管理业务类；封装了一个数据库访问工具IBatis，作为数据库和Java类的Object-Reletionship映射工具。另外，对于商品搜索功能，采用自己开发的ISearch搜索引擎来取代在Oracle数据库中进行搜索，降低数据库服务器的压力。做法比较简单，每天晚上全量将Oracle小型机的数据dump出来，Build成ISearch的索引，当时商品量也不大，一台普通配置的服务器，基本上可以将所有的索引都放进去，没做切分，直接做了一个对等集群。 

从2006年开始，淘宝为了改善用户体验，开始建立自己的CDN站点，由于淘宝的主要流量来源于各种商品图片、商品描述等静态数据，自建CDN可以使这些资源离用户更近，提升用户访问速度，改善用户浏览网站的体验。

2007年，淘宝全年的交易额超过400亿元，平均近1亿多一天，每天有100多万笔交易被创建。当时面对的几个主要问题是：一些系统的流量非常大，如商品详情等，如果直接访问数据库，会导致数据库压力非常大；如用户信息，访问一个页面，都需要查询买家信息、卖家信息、显示出买家的信用、卖家的服务星级等。此时，淘宝采用分布式缓存TDBM（Tair的前身）将这些热点静态数据缓存在内存中，提高访问性能。另外，将自己研发的分布式文件系统TFS部署在多台x86服务器上，取代商业的NAS存储设备来存储淘宝的各种文件信息，如商品图片、商品描述信息、交易快照信息，来达到降低成本和提高整体系统的容量和性能的目的，同时可以实现更灵活的扩展性。第一期上线大概200台TFS服务器。另外，将ISearch搜索引擎改为分布式架构，支持水平扩展，部署了48个节点。图3展示了这一架构思路。

图3

2008年初，为了解决Oracle数据库集中式架构的瓶颈问题（连接数限制、I/O性能），将系统进行了拆分，按照用户域、商品域、交易域、店铺域等业务领域进行拆分，建立了20多个业务中心，如商品中心、用户中心、交易中心等。所有有用户访问需求的系统，必须使用业务中心提供的远程接口来访问，不能够直接访问底层的MySQL数据库，通过HSF这种远程通信方式来调用业务中心的服务接口，业务系统之间则通过Notify消息中间件异步方式完成调用。图4是淘宝的分布式架构图。

图4 

从2010年开始，淘宝网重点着眼于统一架构体系，从整体系统层面考虑开发效率、运维标准化、高性能、高可扩展性、高可用、低成本方面的要求，底层的基础架构统一采用了阿里云计算平台（图5），使用了SLB、ECS、RDS、OSS、ONS、CDN等阿里云计算服务，并通过阿里云服务提供的高可用特性，实现双机房容灾和异地机房单元化部署，为淘宝业务提供稳定、高效和易于维护的基础架构支撑。

 图5

在从IOE架构最终向云计算平台技术架构转移的过程中，主要面临以下几个技术挑战。

■ 可用性：脱离小型机和高端存储的高冗余机制，采用基于PC服务器的分布式架构的云计算平台能否做到高可用。

■ 一致性：Oracle基于RAC和共享存储实现的物理级别一致性，基于RDS for MySQL能否达到同样的效果。

■ 高性能：高端存储的I/O能力很强，基于PC服务器的RDS能否提供同样甚至更高的I/O处理能力，MySQL和Oracle对SQL的处理性能是否相同。

■ 扩展性：业务逻辑如何拆分，如何服务化，数据分多少库分多少表，什么维度分，后期二次拆分如何更方便等。

基于阿里云计算平台，通过采用合适的技术策略和最佳实践，包括：应用无状态，有效使用缓存（浏览器缓存、反向代理缓存、页面缓存、局部页面缓存、对象缓存和读写分离），服务原子化，数据库分割，异步解决性能问题，最小化事物单元，适当放弃一致性。以及自动化监控/运维手段包括监控预警、配置统一管理，基础服务器监控，URL监控，网络监控，模块间调用监控，智能分析监控，综合故障管理平台，容量管理。可以很好地解决以上问题，从而达到整体系统的高可扩展性、更低的成本、更高的性能和可用性的实现效果。

迁云架构最佳实践

淘宝的技术架构是一个伴随业务逐渐发展而逐步演进的过程，中间沉淀了很多宝贵的架构最佳实践。对于大部分企业级客户来说，可以结合自己的业务场景选择合适的技术架构来实现整体IT系统的互联网化设计。不同应用场景下的迁云架构，包括文件存储、应用服务、OLTP数据库、OLAP数据库。

对于文件存储方式，可以直接用OSS取代EMC存储实现海量数据文件的存储，OSS存储最大容量可以达40PB，同时由于OSS是分布式存储方式，可以通过多个节点的并行读写显著提高数据访问性能。对于大文件，还可以通过Multipart Upload的方式，将大文件分块并行传输与存储，实现高性能。

对于应用服务，可通过SLB+多台ECS实例组合取代IBM小型机（图6），也可以根据不同应用类型，直接基于ACE、ONS、OpenSearch等阿里云中间件云服务部署。

 图6

 OLTP应用的迁移相对复杂。目前阿里云的RDS实例最高是48GB内存，14000IOPS，1TB的存储容量（SSD存储），支持MySQL和SQL Server。这个配置作为单数据库服务器来使用可以满足很多场景的数据库应用需求，可直接取代大部分场景下的IBM小型机+Oracle数据库+EMC存储。

对于性能要求更高的应用，可考虑引入开放缓存服务OCS，将部分查询数据加载至分布式缓存中，减少RDS的数据查询次数，提升系统的数据查询并发效率和降低响应时间，如图7所示。

图7 

对于读的请求远大于写请求的场景，可以考虑用多个RDS数据库，采用分布式方式实现读写分离，写交易主要发生在主库，读请求访问备库，可以根据需求对读库进行扩展，以实现整体请求性能的提升。

图8 

对于数据规模较大的数据库表，可以通过水平切分的方式，将数据分布在多个RDS实例上，通过并行的分布式数据库操作来实现性能和容量的提升。

图9 

总的来说，通过迁移到RDS、引入数据缓存、分库分表、读写分离等多种方式可以用Scale-Out方式取代原有的IOE架构，并且获得更好的性能和扩展性。

 图10

对于OLAP应用，可采用ODPS+OTS+RDS/ADS的解决方案取代小型机+Oracle DB+OLAP+RAC+EMC存储解决方案，如图11所示。

图11

总体来看，迁云的通用架构方案如图12所示，针对具体业务系统的迁云方案还需要根据实际情况进行分析和合理选择。

图12

想知道更多？扫描下面的二维码关注我

后台回复"技术"，加入技术群后台回复“k8s”，可领取k8s资料


【精彩推荐】

• 原创|OpenAPI标准规范

• 中台不是万能药，关于中台的思考和尝试
  

• ClickHouse到底是什么？为什么如此牛逼！

• 原来ElasticSearch还可以这么理解

• 面试官：InnoDB中一棵B+树可以存放多少行数据？

• 微服务下如何解耦？对于已经紧耦合下如何重构？

• 如何构建一套高性能、高可用、低成本的视频处理系统？

• 架构之道：分离业务逻辑和技术细节

• 星巴克不使用两阶段提交
  

点个赞+在看，少个 bug ????