阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.broadview.com.cn/article/419460 「许令波」欢迎转载，保留摘要，谢谢！

• 阶段一 从PHP 到Java
• 阶段二 分布式改造
• 阶段三 无线化改造
• 阶段四 中台改造
• 阶段五 国际化

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

一个创业公司起步时很可能就两台机器，一台Web 服务器、一台数据库服务器，在一个应用系统中集成了所有功能模块，但随着业务的发展、流量的增长，单应用远远不能满足业务需求。

下面我们一同来聊聊网站架构发展所经历的几次主要演进，包括：从PHP 到Java 的改造、分布式改造、无线化改造、中台的改造、国际化改造。

阶段一 从PHP 到Java

很多网站早期都是基于Linux+Apache+MySQL+PHP 架构的网站，从当时来看，这种非常流行的个人网站架构的确也非常匹配当时的发展状态。PHP 语言的特性是快速发布，从页面渲染到数据库访问，均可以在一个页面里全部搞定。

即使放到今天，这种架构仍然还有很多人在用，它的优点就是非常简单高效，但缺点也非常明显：扩展性和分布式不好，不适合企业级的、复杂业务逻辑的大规模协同开发。

随着网站的发展，大家觉得应该将PHP 切换到Java。为什么要切换到Java 语言呢？一般来说，企业选择开发语言会有如下考虑。

（1）语言本身的特性。每种语言开发出来都有它的特性和所适合的场景，像Python、PHP 这类脚本语言非常适合快速简单的开发方式，而Java 则比较适合构建复杂业务逻辑的企业级开发，但是开发效率会比PHP 要差一点。

（2）程序员队伍。企业选择何种开发语言，还要看市场上的人才队伍是不是足够，是不是有很高层次的人才。是否有高层次的人才，取决于当前的行业老大是不是也在用这种语言，比如当前的顶级互联网公司如果在用Java，那么自然这些公司的Java人才比较多，这样，他们的经验可以被快速复制到其他公司中。

（3）语言所对应的工具生态是否完善。一个语言是否有生命力，要看这个语言对应的生态工具是否完善，它的社区是否活跃。因为我们要用到各种工具，而我们也不可能自己去写每种工具，因此，是否能方便地利用开源工具，快速提升开发效率也是非常关键的。像现在很多大公司开源了很多Java 的中间件产品，这些中间件可以直接拿来使用，就不需要再重新开发了。

综合以上因素，电商网站选择Java 语言作为主要的系统开发语言是非常合适的。

从PHP 切换到Java 后，整个网站采用WebX+EJB+iBatis+JBoss+Oracle（后面又将EJB 改成Spring）的架构，但是随着业务量的不断增大，存储层的瓶颈暴露出来。

为了解决存储问题，就逐渐用上了非常昂贵的IBM 小型机、Oracle 的数据库以及EMC的高端存储（IOE）；并对数据库做了分库的拆分，分布式缓存（Tair）也随之诞生，分布式文件系统TFS 开始出现，CDN 也慢慢建立了。

阶段二 分布式改造

所谓分布式改造，就是尽量让系统无状态化，或者让有状态的信息封装在一定范围内，以免限制应用的横向扩展。简单来说，就是即便某个应用的少数服务器“宕”掉，也不会影响整体业务的稳定性。

要实现应用的分布式改造必须先解决以下几个问题。

（1）把应用微服务化：即将大量粗粒度的应用逻辑拆小，做服务化改造。

（2）必须先建立分布式服务框架。必须具备分布式RPC 框架、异步消息系统、分布式数据层、分布式文件系统、服务的发现、注册和管理。

（3）必须要解决分布式Session 问题。

为了做业务的服务化改造，我们大量拆分了当时的业务系统，形成了商品中心、交易中心、用户中心、店铺中心。这些服务作为底层服务供上层的前台系统调用，此时的系统架构变成了下面的形式。

现在来看，系统的分布式改造为网站接下来5 年的发展奠定了很好的基础，整个网站的扩展性非常好。几乎每个初创企业都必须经历一次分布式化的改造，才能为企业的长期发展奠定基础。笔者前面提及的几个重要的中间件产品和关键的分布式Session 等技术在《深入分析Java Web 技术内幕（修订版）》一书中有详细的介绍，感兴趣的读者可以自行去学习了解。

阶段三 无线化改造

到了2013 年，无线技术已经非常火爆了。在此之前，无线的业务总是跟着PC 走，基本上是PC 做好后无线再复制一份，而且无线和PC 还不是同一个前台系统，导致一个功能要做两遍，并且无线部门的开发人员本来就不多。这些给业务的发展带来很多问题。因此2013 年底，启动了All in 无线项目，目标就是用一套系统、一套架构快速支撑多端的个性化，并在服务端做了很多模块化和组件化的改造。

随着无线技术的发展，我们也开始尝试一些新技术，最具代表性的就是Node。

Node 在业界很火，前端同学非常推崇，而且它也大幅提升了前端的开发效率和体验。

目前大家也多方尝试使用Node 技术，并且用在一些业务线上。但是，从今天来看，Node 并没有达到我们想象中的发展前景。这其中有多种原因，本书的后续章节会专门介绍网站的无线化改造实践，也将分享Node 在实际使用中的一些思考。

经过无线化改造的应用系统架构如图。

阶段四 中台改造

中台这个概念早期是由美军的作战体系演化而来，技术上的“中台”主要是指学习这种高效、灵活和强大的指挥作战体系。电商经过十几年的发展，组织已经庞大而复杂，业务不断细化拆分，也导致野蛮发展的系统越来越不可维护，开发和改造效率极低，也有很多新业务不得不重复造轮子，所以中台的目标是为了解决效率问题，同时降低创新成本。

阶段五 国际化

国际化一般会有两种思路：一种是一套原始代码部署到多个地方，各地的系统基本没有什么关联、保持相互独立，每个地方再根据本地实际情况做一些个性化的定制。一般来说，会精简原始代码，减少不必要的依赖。这种思路在一些跨国公司用得比较多，但是这个对技术要求比较低。

另一种思路就是我们所说的国际化，它主要是解决如何将一套系统部署到多地的问题。一般国际化有两个发展阶段：第一个阶段是在国内实现了交易的单元化；第二个阶段是实现了中美的跨国部署。

国际化的本质仍然是要解决以下的通用问题：多语言问题、多时区问题、数据路由问题、全球数据的同步与复制问题。

本文摘自《大型网站技术架构演进与性能优化》一书前言，作者许令波 ，电子工业出版社6月出版。

罗马不是一天建成的，能够支撑亿级交易量的大型网站也不是一蹴而就的。作者以一名亲历者的身份，阐述了一个大型网站在数年时间内从雏形成长为巨人时所经历的技术选型思考、方案选择，以及遇到的众多性能瓶颈和优化方案。

本书要表达的内容并不是简单罗列所做过的事情，而主要是帮助读者了解当网站遇到类似问题时，应如何思考不同的解决思路、为什么要这样做、如何做出最终的方案选择……