可伸缩性架构设计.pdfVIP

可伸缩性架构设计 谢新华 一、项目概念 目标客户是历史上具有悠久的传统和成就的大公司，原来的管理和设计模式上采用层 次化垂直结构，利用这种结构打造了一个具有固定业务、确定交互、可以重复执行的高效企 业模型，这个模型曾经是高效率的也是正确的。 但是近年以来，随着用户对产品更新换代的要求越来越快、质量要求越来越高、竞争 日益剧烈、外部压力日益增长，迫使这个企业在管理模型上重新定位，打碎长久以来形成的 垂直结构，保证产品需要具有多样性、弹性和专业性，逐步相成一种趋向于水平集成的业务 模型，也就形成了企业重构的趋势。 这种企业业务模型的解构趋势，也就是各个企业将根据自己的能力进行业务上的专业 化分工。让一个企业主要专注于自己的核心业务，核心业务以外的任务将外包给第三方来提 供实际的支援和交付，每个第三方再将重点放在提高自身的核心服务上。他们认为，这种由 业务伙伴、供应商和客户形成的更多合作与互动，将会使他们向新的业务空间发展，并以更 快的速度和更高的质量，为客户提供更加先进的设计和产品。 于是，当初封闭的企业内设计管理模式，无法应用于异地合作方协调设计环境，这就 需要搭建基于互联网的合作方协同沟通平台，让部件设计合作方在早期就介入产品的研发过 程，以缩短主要设计部门和合作方的沟通时间，提高合作方在新产品设计中的响应能力，实 现各方共赢的局面。 可见这个软件产品对于用户具有相当大的价值，是值得认真对待的。 为此，项目组为项目起了一个好听的名字：Acura， 给项目起合理的名字非常重要，因为人类就是一个喜欢命名的生物。如果你认真给项 目起名字，就意味着你非常在意这个项目，并且会仔细思考认真呵护这个项目。后续的所有 人员包括编码员、测试人员等都会认真地给变量或者方法命名，使项目的可读性增加而且整 洁，清洁的产品将从命名开始。项目的初步架构概念如下图所示。 系统中各独立部分的位置关系体现为传统的分层结构，而整体上用服务的特征来分布， 1 而服务又分为栈服务与元服务两个层次，如下图所示。 注意，前期并不需要做庞大的前端设计，而只需要一个简单的概念模型。图中的这些 大块，可以随着功能模块的添加而轻松的增长。这种基于服务的架构使得每一部分保持高的 内聚，并尽可能减少相互间的耦合，开发每一部分的程序人员并不需要过多的关注其他部分， 增强了系统的可理解性，而且开发的专业性很集中，也保持了概念上的一致性。 这个架构虽然很基本，但是却为增长提供了坚实的基础。回想前面的例子，那个系统 没有总体规划，只是在方便的地方嫁接和修补功能。这里之所以称之为规划，是因为初始设 计需要一定的抽象性，而不是面面俱到。 二、可伸缩性架构设计问题 1 1 11，为什么要考虑可伸缩型问题 在进行Acura系统初始概念确定之后，我们需要对某些宏观架构概念作更细腻的分析。 一个需要集中思考的问题，就是如何确保系统在伸缩的时候的弹性。随着越来越多的系统在 互联网上提供访问，伸缩性变得越来越重要。因此在这个项目中，我们对系统的可伸缩性问 题作了更加深入的讨论，从而改变了初期确定的架构。为什么要研究可伸缩性问题呢？ 1 1 11）系统处于极其容易变化的环境中，难以进行初期的容量规划 当一个系统处于极其容易变化的环境中时，初期的容量规划有时显得比较荒谬，因为 到底系统运行后会发生什么？谁也无法预料。 2 2 22）系统规模和特征可能会发生变化 对于一个水平模型大型离岸合作方协同设计系统，初期的合作方可能比较少，关系也 比较简单。到后来可能有相当多的合作方形成巨大的商业设计网络。在商业运营进一步开展 的过程中，这些合作方在数量和业务范围上还会发生许多变化。与普通Web系统只是提供 静态内容不同，这些合作方的每一个相关用户，不但需要与中央企业进行交互，也需要彼此 之间进行交互（例如在三维空间中修改设计、相互探讨）。这类交互使得这类系统伸缩性问 题变得更加复杂。 3 3 33）系统的应用特点是并行性 对于任意两个参与者，在某个时间进行交互的可能性是比较小的，但几乎所有的人员 在所有的时刻都在与他人进行交