3        系统变迁

       话说天下大事，分久必合，合久必分，在计算机的历史中也有借鉴。从最开始的终端主机模式到客户端服务器模式，到J2EE的3层结构，乃至集群和分布式结构，把系统不断的拆分和抽象，当分布式的服务器到了一定的规模，远远的看去，又像了一套硕大无朋的主机，只是高高的挂在天上。只是一个是从云端鸟瞰大地，俯视芸芸众IT民工；一个是仰望星空，感慨云卷云舒遥不可及。历史划了一个圈，仿佛又回到了起点，其实不然，此时的云计算和当年主机感观上可能有些相似，但内部机理已经完全不同，是一个螺旋式上升的趋势。

       本文中结合平台研发部中所有同事的劳动成果、自己在项目推广应用中的感悟和体会，以及一些思维的外延，并尽可能用能阐述清楚的文字或者图片，说明如何从云端到具体落地的过程，尝试在基于云端项目推广中，减少和项目之间的交流和沟通成本，尽快的为项目的实施和落地，做点自己力所能及的事情。

3.1 系统的演变

       系统的演变从来都是外界的需求而产生，无论是被动也好，还是未雨绸缪，每次演变都是为了解决需求的一部分问题。本文不讨论具体的业务问题，主要是考虑在互联网形势下，大型系统应有的结构和功能。一般来说有具体的场景和事例讲解起来更贴近现实，不过因为公司内部没有这么大的系统，也没有这样的相关经验，相关的资料也是麟毛凤角，要不简单，要不就是高度抽象，只能多方收集资料，再加上自己的一些想象和理解。      

       国内顶尖的互联网公司有4个，分别在各自的领域占据绝对领导地位，腾讯，百度，淘宝，盛大，以及一些在各自细分的专业领域中的领导地位的公司，比如优酷和土豆，当然他们现在结婚了，变成优豆了；比如在卖书行业，当当，豆瓣等。

       根据公司的规划的5条产品线，以及支撑的一些项目来看，最和我们公司业务贴近的是淘宝，所以在组件的开发，架构的设计，以及基础设施的搭建上，借鉴和学习淘宝就是一条可行的方式。淘宝的组件基本开源了，包括分布式服务框架，大数据文件系统等，其他的文档和资料也能检索到，极大的提高了国内开源社区的力量，提供了一批高品质的组件和设计思想，我们在学习和借鉴之余，向我们的互联网应用的前辈致以崇高的敬意。      

3.1.1            淘宝网站的演进

       既然从业务上归类，我们和淘宝有些类似，那就借鉴淘宝的一些资料和图片，看看淘宝网站是如何破茧而出的。首先我们看看淘宝网站的架构变迁编年史。下面这张图阐述了淘宝网站12年来的几次重大变迁：

1. 总的说来，淘宝网站是紧贴时代的变化，是技术的弄潮儿。

2. 每次变化都给淘宝网站带来质的飞跃

3. 目标是更大更强，部署更自动化，管理更智能化

架构规定了软件的高层划分及各部分间的交互：

1. 架构不是软件，但架构决策体现于软件平台和框架之中

2. 架构的优劣决定了业务应用系统的实施能力和发展空间

3. 技术搭台，业务唱戏 à 架构搭台，应用唱戏

   

  图31-01a 淘宝系统的变迁编年史                 

  图31-01b 架构升级后的效果

       任何大型系统的实施和运行，都离不开软件架构，部署方式，物理结构，这些构造了整个系统的生态系统，任何一个短板都造出系统的运行能力下降。

1. 软件架构，包括采用的技术框架，业务的拆分，系统的分层分块，请求路由的处理（粘性会话？服务端处理？客户端处理？），数据库的模式（拆分？集群？大表？小表？）

2. 部署方式，包括画域分区来对应不同的软件模块，采用的web容器，EJB容器，消息服务等，彼此关联的系统的维系，关联的服务启动的先后次序，启动关停的脚本，数据库初始的数据等

3. 物理结构，包括主机的虚拟化，存储的划分，网络的设定，操作系统的状态（启动，关停，正常），以及有此而引申的系统的动态迁移，预警机制等功能。

       作为架构师，以前更多的关注是软件的架构，对部署模型，物理模型不甚了解，但部署模型，物理结构承载的是软件的实现，直接影响系统的性能表现，所以这也是老董说架构师需要了解物理模型的初衷。（从前是项目打成大的war包，分别在几个不同的应用服务器上部署，数据库开启，就算完成了部署）

       淘宝网站从99年到现在，一路走来，从小到大，系统不断的沉淀和发展，乃至现在一种巨无霸的形态，它是如何支撑并且做到的呢，那个时候并没有云。可见，云并不是系统可伸缩可扩展可升级的必要条件，只要心中有云，哪里都是云；心中无云，就算有朵云在我们的身边，我们仍旧是云里雾里，这也就是我们现在的感受，因为我们并不了解云的作用和它的使命，对云有太多的要求，有太多的误解，有太多的期望。

       淘宝是如何在没有云的支撑下做到这点的呢，我没有更多的资料，但我想应该是淘宝在一个时间阶段，形成了一个固定的模式（模式也在不同的阶段中演化和重构，比如早期阶段编写了很多脚本，以及在作了约定和缺省配置），产品经理只需要设计好自己的创意和构思，再和一帮志同道合的同事捣鼓出来，然后遵照一些模式和要求，再统一部署和上线，也就是说，一些基础的模式来保证系统对外界的大并发能力的支撑。

1. 系统按照可拆分的原则设计

1. 无状态模式，session在cookie处理

2. 业务系统被设计能拆分（分布式框架，采用消息等异步方式）

2. 数据库扩展能力

1. 支持数据库的扩展

2. 读写分离，在数据库端保证数据的复制

3. 基础能力封装，直接调用即可，提供通用的业务支撑能力

1. 大文件系统，存储海量数据和文件（包括小文件系统）

2. 后台处理能力

3. 消息能力

4. 有成熟的部署脚本，能快速的部署和回滚，并有一套流程和保障措施

5. 有成熟的监控处理能力，发现瓶颈，及时预警或自动采取措施

6. 有成熟的底层系统控制能力

1. 快速的产生一批主机（也许是虚拟机）

2. 快速的组网，画域

3. 支持系统的动态迁移（把系统从a区移动到b区）

       从这些来看，淘宝网站已经有了云系统的基础特征，而且也有了外部的需要拉动，需要更好的基础设施来支撑业务的上线，升级，部署，以及运营。淘宝的资料里面，有句话“业务唱戏”à“应用唱戏”的转变，这个应用其实包括了比业务本身更多的内容，比如创建脚本，依赖关系，自动检查和依赖检查以及初始化的脚本语句等等，也许还有其他的内容。所以淘宝网站发展到当前阶段，转openAPI和云计算就是水到渠成的事情了。

来源：timeson http://timeson.iteye.com/blog