ESB zone ? 构建架构的思考

（说明：以下内容仅仅是一种思考，而不是某家公司的具体内容，在此过程中，参考了多篇 DBA Notes上关于一些公司互联网架构的介绍，在此表示感谢！同时参考了其它一些关于架构介绍的文章。很欣赏我同事[程立]的一句话，用中国古典文化阐释架构的源和重要性 — 老子说”道生一、一生二、二生三、三生万物”。在业务愿景的技术实现过程中，假设”道”为愿景、一为方向、二为战略的话，三就应该是架构了，架构既出，万物化生可矣。”）

1. 第一要素

关于什么是架构，已经有很多文章在讨论了，本文不予以探讨。
关于架构的类型，业界的定义也各不相同，《架构的类型》对这个问题进行了探讨，可供参考。
此处所探讨的架构可能包含了企业架构、系统架构、软件架构、信息架构、SOA架构等方面的部分要素，所适用的行业，也仅限于互联网行业。在此，引出了构建良好架构的第一个基本原则：依据业务特征选择架构。例如，Amazon、EBay、FaceBook、YouTube等互联网企业的架构都非常的不同，每家公司都有自己独特的架构特征，首要因素就在于第一要素。

2、第二要素：哲学原则

之所以称之为哲学原则，首先它们比较虚，就像黑洞那么虚；其次度量起来比较困难，没有一个统一的标准，也很难定义标准，例如不同机构对客户满意的定义就不一样；再次它们的确很通用，在架构的各个阶段、各个层面、各种粒度都适用。
它包含如下子元素：

• 使客户(所有直接或间接使用这个系统的人都是客户)满意 – 功能、质量、使用、体验
• 良好的投资回报率 — 复用、免费产品、成型产品
• 足够敏捷，适应业务的发展，且能够快速推出新业务 – 可发展性
• 支撑企业核心竞争力
• 简单又实用
• 强壮又稳定 （ 架构设计必须考虑到故障—业务故障的可恢复性、技术故障的可恢复性，非常状态的故障：电力不足、机房断网、自然灾害等，冗余和错误恢复也是达到稳定的必要手段）
• 术语一致性（有点像统一思想、统一口径）
• 可维护性
• 支持未来的发展
• 对运营友好 （尽可能自动化，是对运营不错的支持）

3、第三要素：量变引起质变 （驱动架构进化的因素）

“量变是指事物单 纯数量上的增加或减少，事物保持其质的稳定性。质变是指事物根本性质的变化，在这阶段，事物处于剧烈的变化之中，其平衡静止被打破，旧的事物转化为新事 物。事物的变化总是先从量变开始的，待量变积累到一定程度后，才会发生质变，其中量变是质变的必然前提，质变是量变的必然结果，量变→质变→新的量变是事 物发展的基本规律”。这条哲学规律同样适用与系统架构，每次大的系统架构的变化，背后的动因都是”量”引起的【类似window这样的系统架构变化的动因，不在此处的探讨】。在互联网领域，如下主体的量起到很大的作用：
基本量：

• 用户 — 总量/日访问量/并发量/增长率
• 访问量（PV） — 日访问量/并发量/响应周期
• 产品 — 数量/业务领域量

被动量：

• 业务数据 — 历史总量/日变化量/并发量/增长率
• 系统日志 — 一段区间总量/日生成量
• 业务日志 — 历史总量/日变化量/并发量
• 事务量 — 日变化量/并发量/响应周期
• 外部网络 — 流量/并发量
• 内部网络 —并发量
• 网络连接 —并发量
• 图片 —总量/日访问量/并发量/增长率
• 项目【包括日常升级、日常BUG维护】 — 平均开发周期/项目组成员增长率/测试周期/发布时间
• BUG — 确定原因周期/响应周期
• 系统服务（SOA角度的服务） — 总量
• 设备 — 总量
• 内部抱怨 — 声贝的大小
• 停机维护 — 次数/时间

基本量是基础，它驱动被动量的变化，例如用户，日访问量会引起业务数据、网络连接等的变化，基本量的变化对架构的影响最大，时刻关注基本量的升降。
【注意：】不用业务领域，重点关注的主体略有差别

4、本文探讨的架构包含的元素

上面是针对互联网产品的一种架构【产品架构和业务架构是都需要针对自身的特点进行划分，不具有通用性】。

• 产品架构的目的

能够描绘当前产品的关系、分类；

能够体现公司的核心价值、核心竞争力；

能够实现公司的战略意图；

能够支撑现有产品的管理和标准化进程、以及未来产品的规划；

能够指导产品的可持续发展、创新；

为技术架构提供产品输入。

• 业务架构的目的

能够描绘当前业务的关系；

能够支撑公司的战略；

能够支撑产品在既定方向上发展；

能够支撑业务的发展和敏捷；

为技术架构提供业务输入。

• 技术架构的目的

能够描述当前的IT状况；

能够支撑对产品的发展；

能够为客户提供高质量的服务【非功能性方面的需求】。

为技术架构选择的几个子架构域：

1. 信息域

   此处的信息特指用户交互层面的信息、跨系统的信息、内部管理的信息。本域内关注用户信息展示、信息聚合、信息共享、信息交换、信息分析和挖掘等。

2. 基础技术域

   支撑IT的基础设施，该域包含硬件基础、系统基础、应用基础环境、通用技术（例如：工作流、ESB、搜索等）、程序驻留环境（类似FaceBook的开放平台）等。

3. 数据域

   支撑数据的存储（数据库存储、文件存储【例如：BigTable】、甚至存储在S3中）、访问（透明统一的访问）、分布（物理分布、水平切分数据、垂直切分数据）、缓存、备份、归档等。

4. 部署域

   支撑系统（此处单指一个独立的物理整体，例如运行在一个JVM上的所有的内容）和服务（单指SOA服务）的运行、管理、发布、分布（同城、异地）、日志等。

5. 治理域

   为公司业务的运营提供不同粒度的（硬件、系统粒度、产品粒度、服务粒度、客户粒度等）监控、报警、控制、隔离，以及服务的版本管理等。

6. 安全域

   为公司业务的安全提供硬件、软件、业务等方面的支撑。

7. 测试域

   为产品提供测试环境、生产环境、沙箱环境、性能环境等的支撑。

8. 分析域

   支撑公司运营、管理、客户分析、智能系统等（从简单的URL分析、到服务路径的分析、定向客户分析等）。

架构的三要素（产品、业务、技术）以战略为核心，战略影响三要素的发展；业务支撑战略、产品实现战略、技术实施战略。

架构的三要素之间互相支撑、互相制衡。

4、良好的架构遵循进化原则

从低级生物到高级生物、从小企业到大企业都遵循了进化的原则，大凡违背这些原则的事物都会消失、失败。架构也是如此，从简单到复杂，逐步进化，逐步发展，每经历一个痛苦阶段，都会带来质的飞跃，都能够再次适应当前的环境，从而获得生存和发展。

1）、决定系统不做成什么样子， 与决定将它做成什么样子同样重要
不去满足所有的需要， 而是让系统具备可扩展性， 使其能够向上兼容。
2）、有进有退
在架构进化的过程中，是所有要素都同步进化吗？我们看看生物的进化过程，在不同的时期有些部件会进化，有些部件会保持不变，甚至有些部件会退化，这是自然选择的结果。架构也是如此，商业环境的变化，公司战略的变化，必然要求我们作出选择 — 可能加强、可能弱化、可能维持现状。
3）、进化的要素
对于产品架构、业务架构的变化主要依赖第一要素、战略、业务指标、营收指标等商业方面的输入。
技术架构层面，具体那些要素应该变化、变多少、如何变，依赖产品和业务架构、第二要素、第三要素的组合输入或者单个输入。例如，第二要素的强壮性，要达到这一目标，可以选择增强测试、增强基础技术架构、增强信息域、加强治理等要素来实现。具体选择哪一个域中的那些要素来开展？这就需要架构依据环境做出适当的选择。
4）、控制节奏
一个好的架构进化过程，就象一曲优美的乐章、一台完美的多幕剧，让所有受众都赏心悦目，赞叹不已。

案例：Amazon 、FaceBook、EBay等，从创立之初到今天，每一家公司的架构都发生了翻天覆地的变化。

6、规划和预测

架构的规划，指在当前情况下，为一段期间内明确路线图，确保我们的进化是有序的，可控的，清晰的；以及容量的规划（系统不是无限可伸缩的，到了一定量级，必然要提前进行质变）。

架构的预测，指在量能不断变化的过程中，提前预估架构可能存在的风险，从而提前实施调整和相关的准备工作。例如：提前研究新产品、提前研究新技术等。

7、因素 — 要素作用表

备注：
A：新增表等类型的操作，不属于数据域变化的范畴【此处探讨的更多是架构一个层面的问题，例如：涉及到数据的分表，那么就属于架构范畴】。
B：用户数量变化时，对于做产品独立销售、SAAS软件等等类型的公司，其作用效果与本文所指有所不同。
C：忽略的意思是不要为其考虑专门的架构，而不是不进行对应域的相关工作。例如测试域，可以不做测试架构方面的工作，但测试却是必须的，即使只有一个人使用的软件，也要考虑测试，部署等方面的问题。
D：描述某一要素的词语”忽略”、”简单”、”仔细”、”专业”等，只表明了一种重视程度，而不是必须达到某一级别。毕竟进化时的选择，是所有外部因素集体作用的结果，而非单一因素必然促使某些要素必然发生变化。

8、一定规模下构建良好架构的一些方法

1. 鼓励异步

   不仅仅是技术的业务，业务也要考虑异步

2. 虚拟化组件

   减少物理依赖，增强部署灵活性

3. 数据切分

   按照某种原则分布存储数据；读写分流

4. Cache

   缓存一切值得缓存的，不得不缓存的内容

5. 避免cluster方案

   带来的麻烦比好处还多

6. SOA思想

   它是一个宝库，在架构的每个层面，都有丰富的研究成果，可供我们汲取

7. 无状态

   把状态都放在存储中，避免带状态的服务

8. 定制部分关键技术架构组件

   通过购买商业软件、使用开源软件可以极大的降低成本，同时加速技术架构的成型，不利之处是：这些通用软件总会存在不适应症、以及不能完全满足我们的非功能性指标。通过对各大网站的架构进行分析，可以发现，对于某些关键技术架构组件的定制，是解决问题的最好方式

9. 技术架构标准化、简单化

   技术架构尽可能标准化，避免不断引进新技术，一切以简单为原则，切忌为了技术而复杂化架构。例如，不是每家公司都必须构建和Google一样的基础技术平台，简单的技术平台一样能够为客户提供高质量的服务；架构的变化一定要遵循量变引起质变的原则，为2年的量而改造当前系统失败的几率会很高。