3.2　云服务架构

云计算软件架构如同大多数软件架构一样，是对实际需求、扩展性、可靠性及性能等需求方面因素，CRM、物流管理、财务管理等专业因素，以及人力成本、开发周期、运营预期及升级周期等众多因素平衡取舍的结果，不会有一个大而全的架构能够适应所有情况；但对于云服务专业化、高并发、高可靠特性这一特点，有设计模式可供参考，下面讲解这些可用于架构设计的模式。

3.2.1　设计的基础模式

1．一致而稳定的抽象层

云计算是通过规模集中及服务专业化来提高服务效率，达到降低使用成本的目标，因此一般来讲，对于云服务系统，需要整合多个不同业务，以满足用户多方面的需求。多个服务是否能够整合，是否能够根据用户需求更换不同的服务提供者，关键的一点就是该服务是否能够抽象成一个高级别的组件，迅速组合，构成满足用户需求的服务，这也是系统可高度配置的基础，以适应在一个平台上快速满足众多企业用户的需求。

因此，云计算提高了抽象水平，所有组件都抽象化或虚拟化，并可用来迅速组合较高级别的应用程序或平台。如果某个组件不向其客户或同行提供一致而稳定的抽象层，该组件就不适合于云计算。如常用的单点登录，将用户认证、用户关系组织成一个公有服务，用户在互联网上登录时，无论在哪个服务上登录，都能够提供身份认证，保障一次登录使用所有应用，同样地，目前社交网络服务（SNS）中，使用微信或LinkedIn网的ID可进行身份认证，将服务提供给更多用户，这是一个典型的用户认证及关系抽象的例子。对于该服务自身来讲，并不处理用户登录，仅仅通过虚拟登录概念，通过不同的适配，达到同样的目的，极大地扩展了服务使用人群。

云计算的SaaS服务大都采用Web服务封装，提供标准服务接口，这样各个客户及其他服务提供者能够简单集成，一起向最终用户提供服务，如上面所说的微信及LinkedIn的服务接口，这样既能保障客户通过微信或LinkedIn获取更多服务，也能够让网站在开通初期，尽快扩大用户群体，是一个双赢结果。

IaaS应用标准部署单位是虚拟机，它本质上可运行于抽象硬件平台。人们很容易过度关注构建虚拟机映像（image），而忽视用来创建虚拟机映像的模式。在云计算中，维持该模式而非映像本身非常重要。该模式是保留下来的，而映像则是从该模式产生的。虚拟机映像始终在变化，因为虚拟机映像内的软件层总是需要修补、升级或重新配置。不变的是创建虚拟机映像的流程，而且这是开发人员所应重视的。开发人员可以通过把Web服务器、应用程序服务器和MySQL数据库服务器叠加在一个操作系统映像上，应用补丁程序、配置更改，以及互连各层组件，来构建虚拟机映像。可以说虚拟机抽象是IaaS服务基础，但本质是虚拟机维护、创建、监控、资源配置与隔离及可靠性保障等的抽象与封装，使得IaaS一致稳定地向不同客户提供服务。

随着微服务架构的兴起，CaaS成为IaaS应用标准部署的子集。容器比虚拟机减少了硬件仿真，依靠操作系统进程级别的隔离，其创建和销毁速度在毫秒到秒级，是一个“轻”沙盒。现在广泛应用于业务在高峰和低谷之间的容量的调整、AI运算和大数据处理领域。

PaaS平台可以建立在IaaS之上。使用虚拟机系统隔离每个用户部署在平台上的应用，虚拟机产生映像时，将平台API相关调用库、认证设置等一次部署到位，而且平台安全、可靠等相关部署事项都可以通过虚拟机方式隔离，让用户开发、部署应用的难度极大降低，这是PaaS服务抽象的常用模式。同样，通过抽象建立业务运行的隔离环境，除业务API外，部署、开通、计费等服务系统必备API都应该是PaaS平台API的一部分，这样就能通过一个稳定的抽象层隔离各个用户发布的服务，当一个服务故障时，不影响其他服务的正常使用。

2．标准化

对于云服务，需要同其他服务提供商、企业服务集成，才能满足企业用户的不同需求，而不同企业用户对不同服务有着各自不同的需求，这就要求对服务的抽象和封装尽量符合行业标准，这样就能快速替换不同服务，满足用户需求。

云计算首先重视效率，因而采用少数标准和标准配置有助于降低维护和部署的成本。拥有可简化部署的标准比拥有用于作业的最佳环境更重要。二八原则就是：20%的标准可以支持80%的使用案例。从成本效益来看，这样的工作可以让高成本的一次性产品开发转变为可以复用的构件开发，从而降低多个项目的综合成本。

云服务一般采用Web Service标准接口，包含RESTful和SOAP两大阵营，随着封装级别提高，RESTful日益兴盛。SOAP由于历史原因，还有大量服务和系统支持，并且由于SOAP工具更成熟，它仍然是许多服务提供接口的选择。考虑到效率、耦合度及开发分发等一系列因素，RESTful可能是高并发系统的最佳选择。

3.2.2　设计的结构模式

1．虚拟与封装

对于云计算服务，将服务接口封装成一个虚拟服务，在创建自己的服务时，使用这些虚拟服务，在虚拟服务实现层，使用proxy模型，封装多个同一服务，在配置中体现不同服务，这样就是在增加更多的应用服务时，最多完成封装适配工作，这样能最大限度地减少不同服务集成带来的影响。

虚拟和封装技术将实现细节隐藏起来，使开发人员重新重视组件之间的接口和互动。这些组件应提供标准接口，以便于开发人员方便快捷地构建应用程序，同时利用与性能或成本所要求的相似的功能来使用替代组件。

云服务开发是有计划地完成的，甚至用来部署服务的程序也要封装，以便于利用和重新利用。可以封装部署三层式Web基础设施的程序，这样，该程序的参数就会包括指向用于Web服务器、业务逻辑和数据库层的虚拟机映像的指针，然后就可以执行此设计模式，便于部署标准应用程序，不必重新设想或重新考虑支持每层所要求的架构。

已经实践了多年的模型总线其实是一种高层次的虚拟与封装过程。如一个有限状态机模型，是对很多有状态系统状态迁徙与行动的封装，通过将状态行为数据化，能够在多个不同部署上，同时对同一业务的不同过程进行处理，这样能极大提升系统的并发能力。同时在处理过程中，由于一个服务可能会使用多个模型，模型总线的概念是将这些模型及之间通信封装成一个松散的、以数据驱动为主的抽象实现，降低在其上实现、部署服务的难度。

2．松散耦合、无状态、原地失败

松散耦合（Loose Coupling）、无状态（stateless）、原地失败（fail-in-place）模式的根本动机是降低耦合。这种耦合包含程序信令处理的逻辑耦合、状态依赖和计算上下文依赖关系等。当各个部分之间采用松散逻辑耦合、无状态依赖和无上下文依赖方式后，每个分片处理都能并发在不同机器上，由于没有状态和上下文，哪个计算单元处理结果都是相同的，这就能够避免因大量用户并发与分布处理导致的状态不一致等错误。同时，每个分片错误发生后可以直接重新开始，也可以在原地处理。这样就为提升系统可靠性、可管理性及高并发提供了依据。目前，基于Web的应用程序已经在向松散耦合和无状态转变。

在云计算中，这些特征更加重要，因为云计算具有更加动态的性质，服务组件越来越动态，而且可能是分布在不同地域，任何组件发生故障都不会影响整个应用程序的可用性，每个组件应该做到“原地故障”，极少甚至不会对服务可用性产生影响，这样既方便系统伸缩，也提升系统可靠性。

由于服务组件越来越具有临时性，应通过将状态推出软件来尽可能地使服务运行处理无状态，从而尽可能地将处理与数据分开。能够做到这一点的技术包括：

·　将状态下推至后端数据库。

·　维护数据的补充副本，Hadoop就使用的这一策略。

·　以cookie的形式将状态推出到用户，或者将状态代码编入URL。

·　使用基于网络的持久性技术，例如GlassFish应用程序服务器的Terracotta或Shoal。

“原地失败”计算对操作活动的影响是，即使是硬件也应该是无状态的，以便于云正常工作。硬件配置应存储在元数据中，这样在发生故障时就能够恢复配置。

3．水平扩展

云服务用户往往会爆炸性增长，云服务在设计和部署时，一定要考虑可伸缩性，当用户数量增加时，能迅速部署，扩展系统容量，同时能够保障系统性能，支持用户快速扩张。水平扩展模式是支持系统提升容量的重要模型。设计服务在水平扩展环境中顺利工作的趋势，意味着越来越多的服务能够很好地适应云服务方式。

利用水平扩展的服务非常重视个别组件发生故障时整个服务的可用性，如IaaS云服务平台是在一个虚拟资源池上构建的，如果任何一个物理服务器发生故障，该服务器托管的虚拟机只需要在一个不同的物理服务器上进行重构。把无状态和松散耦合的应用程序组件与水平扩展技术结合在一起，可促成一种“原地失败”策略，这种策略与任何一个组件的可靠性都没有关系。

水平扩展不必局限于单个云服务。根据服务数据的大小和位置，“超负荷”计算可用来扩展一个云服务的能力，以适应临时性工作负荷增加。在超负荷计算中，云服务的应用程序可能会根据需要吸纳来自公有云的额外资源，等到业务负荷降低时再回到自己的基础架构中。

水平扩展是云服务协同其他服务，通过使用其他服务的数据、计算能力，提升自身服务容量的一个有效手段。