架构

清·龚自珍 《自序》：“乃退自讼，著书自纠……论点画波磔之病百有二十，论架构之病二十有二。”

《新华日报》1942.7.2：“这边的山偶然也有像 桂 南那样一个个山峰独立的，可是大多数仍然结成 南岳 那样的架构。”

清·查慎行 《立秋后一日游行宫后苑赐宴恭纪》诗之二：“岩壑不须多架搆，下因流水上因山。”2100433B

构筑、建造。

间架结构。

在建立虚拟基础架构时,有许多设计要素会有助于形成稳健的最终部署，确保虚拟基础架构长期稳定运行。

虚拟基础架构从底层硬件直到上层的虚拟化软件，有太多因素都需要在规划虚拟基础架构时认真考虑。探讨怎样运用虚拟基础架构逐层分析的方法实现一个新的虚拟基础架构部署，同时提出产品选型、环境规划战略。

需要作出的关键决策之一就是：选定虚拟基础架构平台。虚拟基础架构层负责协调每个运行在您的虚拟基础架构中的虚拟的工作负荷。在为您的虚拟基础架构方案选择一个虚拟基础架构平台之前，请基于您当前和未来的IT工作负载评估扩展性：这些负载如何装载到软件空间来提供软件定义的服务，虚拟基础架构是否能被管理层平台操控，是否能提供足够的计算功能，是否有足够的性能来支持您的应用在虚拟基础架构环境中运作。

由于虚拟基础架构主机需要物理硬件，您当然总会期望能在每个物理主机上尽可能合理地放置最高数量的虚拟机。

您可能会想要了解您的虚拟基础架构组织的历史增长率，以及任何虚拟基础架构扩张计划。例如，如果您的公司计划启用另一个分支机构，通过向虚拟基础架构层中新增一台虚拟化主机，您应该能轻松搞定。相反，如果您打算关闭一个业务部门，您也应该能够轻松地缩减规模。在虚拟基础架构管理程序层向上和向下扩展的灵活程度是选择虚拟基础架构管理工具时需要考虑的重要因素。

此外，这也是为虚拟基础架构方案提升工作负载可用性的好思路。当您的虚拟基础架构平台有更新发布时，当前的虚拟基础架构主机将需要进行升级。在虚拟基础架构主机升级期间，保障运行中的虚拟基础架构的工作负载的可用性至关重要。物理主机必须组成集群来实现高可用性，虚拟基础架构平台必须提供提供故障转移功能以确保工作负载可以在升级之前迁移到另一台主机。

注意不要被（供应商）锁定。市场上的虚拟基础架构供应商并不算少。虽然VMware继续维持虚拟基础架构主导地位，但许多组织计划将VMware vSphere和Microsoft HYPER-V混合部署。

但这是一个好办法吗？某些虚拟基础架构计算功能只有只有特定的虚拟化厂商能够实现。例如，VMware 和 HYPER-V 有 SR-IOV 功能，提高了虚拟基础架构资源密集型应用程序的性能。但是VMware不支持实时迁移虚拟机，而 HYPER-V 不支持为 Linux虚拟机启用SR-IOV 功能。

另一个要考虑的虚拟基础架构设计问题是应用程序的支持。您的业务流程应用程序可能会在您当前部署的虚拟基础架构主机上成功运行，但如果软件需要升级怎么办？您可能需要跟您的虚拟基础架构应用程序供应商沟通，了解他们的虚拟基础架构升级细节，虚拟基础架构升级变化是否会影响到您托管的特定的应用程序。

许多虚拟基础架构应用程序供应商开始采用新的集装箱化开发方法。因此，您可能希望虚拟基础架构部署支持应用集装箱化的虚拟化服务器/主机。

利用不同虚拟基础架构供应商的软件部署虚拟化主机的一个附带好处是，如果在未来某一时刻您的组织决定实施虚拟基础架构私有云，您将拥有更多选择余地。

并非所有虚拟基础架构公共云提供商都能支持源自每一家虚拟基础架构上的工作负载。例如，如果您在HYPER-V 虚拟机上承载您的虚拟基础架构应用程序，并打算迁移到亚马逊EC2公共云，您就需要对这些虚拟机进行转换，才能被基于 Xen 的亚马逊 EC2支持。

由虚拟基础架构主机提供的两个最重要的服务是：存储和网络。

虚拟基础架构存储服务为存储协议、存储阵列和存储网络提供必要的支持。您对虚拟基础架构的选择会直接影响到物理存储层。例如，如果虚拟基础架构部署在一个虚拟化主机上的存储服务程序对存储协议和存储阵列缺乏支持，您就无法访问和利用虚拟基础架构底层物理存储基础设施——您的整个基础架构可能需要进行升级。

您应该选择具备以下特征的虚拟基础架构主机，可以不停机在线扩展存储，整合的物理存储层同时支持数据块存储和文件的存储、更大的虚拟化负载容量。别担心虚拟基础架构空间耗尽。您可以在随时为虚拟基础架构工作负载增加存储资源，但虚拟基础架构物理主机是否支持存储扩展是个问题。如果物理主机不支持存储动态扩展，虚拟基础架构管理将会很艰难。

同时，网络服务层必须提供必要的协议才能支持对物理网络基础设施的管理，同时对虚拟基础架构主机上运行的虚拟机提供网络隔离。

融合的虚拟基础架构具有成本效益并能提供灵活的管理。传统的方法是，通过规划每个虚拟基础架构网络部件的冗余来组建一个高可用和冗余的网络。例如，许多组织使用单独的交换机、网络路径和线缆来部署专用的以太网网络。虽然这办法能有效解决当前虚拟基础架构问题，却难以有效地适应未来虚拟基础架构网络的变化。冗余控制由物理网络层完成，这就增加了在网络组件管理方面的开销。

大多数虚拟基础架构供应商支持融合网络架构，此场景下存储和网络的流量将共用相同的交换机和线路。虚拟基础架构要求您用单个网络适配器来承载各种流量，如群集、虚拟机、管理，等等。

另外，对于虚拟基础架构的场景中，不同的流量需要隔离，理解这一点很重要。这是虚拟基础架构提供某些服务质量功能的必要方法。

架构分析常见的分类有政府CIO架构分析、IT网络架构分析，下面分别对其进行介绍。

架构分析政府CIO架构分析

我国内地的信息化建设起步于20世纪80年代初期。信息技术和互联网的发展为电子政务的发展实施提供了技术条件和平台环境，同时，经济体制的变革也对行政管理提出新的要求。我国加入WTO后，在政务信息化建设上要与国际接轨，需要加快实施电子政务和推进政府职能转变。

政府信息化的各项工作离不开政府信息主管（政府CIO）的有效推进，但在我国政府现行的管理体制中，并没有“政府CIO”的说法，大多数称谓是“IT主管”、“信息中心主任”“信息处处长”、“科技处处长”、“信息公开处处长”或“信息办主任”之类。但从人们对于他们所承担的职责及其角色的描述，可以看出他们实际上是承担了“政府CIO”这么一个角色。这种不同的称谓反映了我国政府信息化制度中，对于完善的CIO组织架构所形成的不同需求。为了使政府CIO的工作得以顺利开展，就必须建立与之相适应的、行之有效的组织机构，来规划、实施信息化的战略。

经过对国内政府机构信息资源管理和电子政务相关部门调研发现，目前国内政府CIO的主要组织结构分以下几种：

（1）“信息办 信息中心”结构

这种结构下的政府信息化工作主要由信息化领导小组及“信息化办公室”组成，信息化办公室下设“信息中心”。　（2）“信息办”主导型

这种结构下的政府信息化工作主要由信息化领导小组及“信息化办公室”组成，信息化办公室下没有“信息中心”。

（3）“信息中心”主导型

这种结构下的政府信息化工作主要由信息化领导小组及“信息中心”组成，没有信息化办公室。

（4）“职能处室”主导型

这种结构下的政府信息化工作主要由信息化领导小组及相关职能处室组成，没有信

息化办公室和信息中心。具“职能处室”主导型主要包括两种：一种是以科技处为代表的职能处室主导型，一种是以办公室或秘书处为代表的职能处室主导型。

形成以科技处为代表的“职能处室主导型”的主要原因，是由于某些单位以前的业务中涉及到专业技术的应用，职能部门中有技术处这一部门，因此，在政府信息化的时候，就将与信息技术有关的管理工作全部放在科技处下。典型的单位是公检法。

以办公室或秘书处为代表的职能处室主导型则由办公室或秘书处中的某一个人来承担信息化的工作，这种类型的单位一般是信息化程度比较低，应用相对简单。不需要专门的部门和专门的人员来进行管理。

（5）“职能处室 信息中心”型结构

“职能处室 信息中心”型结构也主要包括两种：一种是以科技处为代表的职能处室 信息中心，一种是以办公室或秘书处为代表的职能处室 信息中心。

（注：虚线表示信息中心并不是直接在其下面的部门，而是在业务上服从的关系）

（6）业务部门主导型

这种结构下的政府信息化工作主要由信息化领导小组及业务部门组成。具

架构分析IT架构分析

BI(Business Intelligence)一词是由Howard Dresner在1989提出的，用来描述一种透过特定的概念与方法，让企业制定决策时能立基于事实基础之上。

为了实现这个目标，软件商各自发展出BI的解决方案，实现的技术各有擅长，但简单而言，便是从搜集数据、整理数据、分析数据的过程，最终再呈现给分析人员。每经过一个步骤，资料数据就好像经过粹练一样，更具价值。

从IT系统的角度而言，广义的BI包含了ETL工具、数据仓库(或数据超市)、在线实时分析引擎和动态报表工具。底下我们将从BI架构分析各组件的组成。

（1）ETL工具

ETL是将数据进行撷取、转换与加载的过程，数据撷取必须从不同的数据库、应用程序，甚至是非结构化的文件，取得数据来源;转换则包含了像是格式转换、数据加总、合并或是过滤有问题的数据;加载则是将转换后的数据抛转到数据仓库。

（2）数据仓库/数据超市

数据仓库从定义来说，是具有主题导向、数据整合与时间性的数据库，它和一般在线交易系统(OLTP)不同之处在于，它储存的不是目前营运交易的数据，而是经过整理、汇总后的资料，让不同来源的数据拥有一致性的格式、名称，以免造成混乱。

由于数据仓库以查询为主，修改机会不高，因此专门设计作数据仓库用途的数据库，会针对这个特性去设计加速查询的方法。

数据仓库之外，也有数据超市这个概念相似，但规模较小，应用目的更为明确的数据汇整方式。数据超市虽然有成低本、建置快的优点，然而一旦企业需要跨不同的数据超市才能查询结果时，则会形成瓶颈。

（3）在线实时分析(OLAP)

在线实时分析工具主要是提供使用者可以实时产生多维度的数据，以进行下钻(Drill down)、Slice、Dice、枢纽等种种不同分析。

在线分析工具可以让使用者从不同维度来探索资料，这种分析方式让使用者可以不用依赖IT部门，自行建立问题分析报表，信息的取得更为实时，也更能有效支持决策。

在线实时分析因为数据模型建立的方式不同，可以分为ROLAP、MOLAP。

ROLAP：针对建立在关系型数据库中的数据进行分析

ROLAP指的是关系型在线分析系统，数据仍采用传统关系型数据库的储存方式，再透过中继数据的对应，产生分析所需要的结果。 ROLAP能储存的数据量大，但是效能逊于MOLAP系统。

MOLAP：针对建立在多维度数据库中的数据进行分析

MOLAP指的是多维度在线分析系统，在储存数据时，便是以Cube(立方体)的概念储存，因此在进行多维度分析时便相当容易、快速。 MOLAP虽然速度快，但是受限于数据结构，可以储存的数据量受到限制。另外一旦需要的数据不在原有的维度中，就无法进一步查询。

HOLAP：对储存在两种数据库中的数据进行分析

面对ROLAP和MOLAP各有优、缺点的情况，因而有HOLAP这种混合两者的新在线分析系统出现。检视合计数据时可以透过MOLAP数据库，而需要明细数据时则使用ROLAP数据库，透过这种方式解决鱼与熊掌不可兼得的困境。

（4）动态分析报表

在OLAP之上，有支持实时性分析的动态报表，和过去静态报表不同之处，就在于它能实时呈现分析结构，无需再重新执行报表产生的过程。动态报表除了支持上述的一些分析方式之外，也有越来越多厂商支持灯号、仪表盘、计分卡、地图等种种图形化的接口，让分析结果能更直觉呈现。

推荐序一

如何看到一滴水的美丽

支付宝（中国）公司业务架构师

《大道至简》作者周爱民（aimingoo）

【一】

架构是一个过程，而非一个结果。

【二】

在大多数人的谈论中，架构是一个目标产物，而作为架构师的责任就是去生产它。所以无论如何，架构是可以“做”出来的，而且也应该有一些“做”的方法、技术、技巧。

有人问过我：架构的最主要产出是什么？我的答案是：图。这里面有两层含义：一层含义是如同建筑师描绘的蓝图一样，用于引导实施者；另一层含义是架构师头脑中清晰的目标系统。如果架构师头脑中没有系统清晰的图像，他是没有办法把它画出来的。

【三】

画家画的无非是物我。画物的画家，最终画的还是我见。所以，画家的笔最终描绘的是他自己心里的映像。

【四】

艺术是不可能被“生产”出来的，生产出来的，叫“艺术品”。

【五】

架构这个过程，是架构师洞见系统内在结构、规律、原则和逻辑的过程。真正的架构师是可以将自己放在系统中去的（例如作为系统中的任何一个角色），只有清晰地理解系统，才能简洁地描述它。而当架构师拿出了他所描述的“作品”的时候，架构这一过程就已经结束了。

【六】

一滴水滴落的过程中，有多少个形态的变化？

推荐序二

架构的架构

北京无限讯奇信息技术有限公司产品技术高级总监

黄冬

感谢译者和出版者为我们带来这样一本传奇的架构故事书。

推荐序三

美丽架构之道

《构建高性能Web站点》作者

Web架构实践者

郭欣

我无法给架构下一个简单的定义，因为任何定义都会束缚你对架构的无限想象。不可否认，架构师早已出现在人类几千年前的各项生产活动中，比如建筑、音乐。而在计算机软件及Web领域，架构的设计直接影响着系统的生产，比如开发过程和效率、代码和组件复用性等，同时也影响着系统的可用性、可伸缩性、性能、容量可预测性等。

在本书中，我们更加关注架构之美。美丽的架构同样无法定义，可它却一定是自然的、简单的、可复用的、人文的，甚至是外行人也可以细细品味其思想的。当我看到超市的多个收银台排满长队时，便想到服务器并发处理性能和容量；当我看到十字路口的车辆等待转弯时，便想到它通过缓存思想来提高交通吞吐率。

那么如何设计出美丽的架构呢？从代码逻辑到物理网络，从单机到分布式，无数的技术可供架构师选择，如分层、组件化、服务化、标准化、缓存、分离、队列、复制、冗余、代理等，不过它们仍然只是“术”的范畴，而何时何处如何恰到好处地使用它们才是“道”的范畴，比如顿悟变化的道理，在博弈中寻找平衡，以系统化的角度来分析问题，寻找相对与绝对的奥秘、开放的心态……

然而，这个领域实在是太年轻了，我们需要更多的例子和经验，本书将让你大开眼界！