分布式系统开发实战：Cloud Native架构，Cloud Native特性

Cloud Native特性

Cloud Native是一种以云架构为优先的应用开发模式。那么这种开发模式又有怎样的特点呢？它与分布式系统、微服务架构之间又存在怎样的联系呢？本节将为你揭晓这些答案。

 以云为基础架构

顾名思义，Cloud Native以云作为基础架构。开发应用时，首先应考虑能够使用最大化的云基础设施。

举例来说，有一个创业项目，需要发布10个微服务，在考虑部署的方式时，应首选云基础设施。理由如下。

·10个微服务意味着需要10台主机，购买这些主机将是一笔不小的费用。

·如果企业需要从0开始架设这些主机，需要配置额外的网络管理员。

·为了保障主机能够正常运转，需要配置额外的运维工程师，并且需要运维工程师全天候值守。

·需要挨个安装容器及应用运行环境。

·需要安装主机监控软件。

从0开始架构基础设施是困难的，最为重要的是，我们没有这么多时间从0开始。特别是互联网应用，谁越早进入市场谁就越有机会把握话语权，毕竟“一万年太久，只争朝夕”。此时，花费少量的资金，选择一款合适的云基础架构设施，便是非常正确的选择。云基础架构设施，使你站在巨人的肩膀上，更能专注自己的核心业务，并且更快地推出产品。

云基础架构设施就是IaaS。现在，市面上有大量的云基础架构设施可供选择，大多数的云供应商都提供了这些云基础架构设施，比如Amazon、Azure、阿里云、腾讯云、华为云等。

云服务

云服务就是PaaS以及软件即服务（Software-as-a-Service，SaaS）的总称。云服务可以帮助用户减少搭建平台所需的时间和成本。以Azure为例，Azure提供了诸如计算服务、存储服务、网络服务、Web和移动服务、数据库、智能和分析服务、物联网服务、企业集成、安全和标识服务、开发人员工具、监视和管理等在内的众多云服务，用户需要什么样的服务，只需要选购相应的服务。

云服务一般是按需计费的，甚至有些服务是免费的。还是以Azure为例，Azure提供了MySQL关系型数据库服务，所需费用仅为0.09元/h起。而如果是使用Azure的多重身份验证，则是免费的。

 无服务

在目前主流云计算IaaS和PaaS中，开发者进行业务开发时，仍然需要关心很多和服务器相关的服务端开发工作，比如缓存、消息服务、Web应用服务器、数据库，以及对服务器进行性能优化、考虑存储和计算资源、考虑负载和扩展、考虑服务器容灾稳定性等非业务逻辑的开发。这些服务器的运维和开发，知识和经验极大地限制了开发者进行业务开发的效率。设想下，如果开发者无须在服务器实现和部署服务，而直接租用服务或者开发服务而无须关注如何在服务器中运行部署服务，是否可以极大地提升开发效率和产品质量？而这种去服务器而直接使用服务的架构，我们称之为无服务器架构（Serverless架构）。

无服务架构是新兴的架构体系，业界也没有一个明确的对于无服务架构的定义。无服务架构可以理解为是SaaS更进一步的发展。MikeRoberts认为的无服务架构主要有下面两种形式。

·首先，无服务架构用于描述依赖第三方服务（“云端”）实现对逻辑和状态进行管理的应用。这些应用包括典型的富客户端应用，比如单页Web应用或移动应用，它们使用基于云的数据库如Parse或Firebase，还有授权服务如Auth0、AWS Cognito等，这类服务以前曾经被描述为BaaS。

·其次，无服务架构也可以指这样的一类应用，一部分服务逻辑由应用实现，但是与传统架构不同在于，它们运行于无状态的容器中，可以由事件触发，短暂的，完全被第三方管理。另一种观点认为这是函数即服务（Functions-as-a-Service，FaaS），而AWS Lambda就是一种流行的FaaS实现，当然还有其他。

可扩展

为了更快地开发软件，我们需要考虑各级的规模。从一般意义上说，规模是产生价值的成本的函数。降低这个价值的不可预测性水平被称为风险。由于构建软件充满风险，我们不得不在这方面限制规模。然而，开发人员往往被要求以更快的速度向生产环境提供功能，这在一定程度上将增加运营风险，而这些风险并不总是为运维人员所知。这样做的结果是运维人员将越来越不信任开发人员所生产的软件。

Cloud Native推崇DevOps方法论，即开发人员与运维人员处于同一个团队，甚至开发人员与运维人员是相同职责人，换言之，开发和运维要在职责上做统一。这也是Amazon所推崇的“谁运维，谁负责”的原则。

实施了DevOps之后，就能第一时间获知生产环境的应用运行情况，并能第一时间对产品调整做出决策。当我们的应用需要更多的计算资源的时候，便是对系统进行扩展的时机。

使用Cloud Native带来的便利之一就是实现了可扩展性。有些云供应商也提供自动扩展的能力，这样，服务实例就能够根据实际的流量的规模来自动扩展应用规模或者削减应用规模。

自动扩展是一种基于资源使用情况自动扩展实例的方法，通过复制要缩放的服务来满足服务等级协议（Service-Level Agreement，SLA）。

具备自动扩展能力的系统，会自动检测到流量的增加或者减少。如果是流量增加，则会增加服务实例，从而能够使其用于流量处理。如果是流量下降，则系统从服务中取回活动实例从而减少了服务实例的数量。

实现自动扩展机制有很多好处。在传统部署中，运维人员会针对每个应用程序预留一组服务器。通过自动扩展，这个预分配将不再需要。

因为这些预分配的服务器，可能会导致在很长一段时间内未充分得到利用，从而演变成一种浪费。在这种情况下，即使邻近的服务需要争取更多的资源，这些空闲的服务器也不能使用。通过数百个微服务实例，为每个微服务预分配固定数量的服务器并不利于成本效益。更好的方法是为一组微服务预留一些服务器实例，而不用预分配。这样，根据需求，一组服务可以共享一组可用的资源。这样，可以通过优化使用资源，将微服务动态移动到可用的服务器实例中。

下面，我们将讨论常用的自动扩展的方法和策略。

1.根据资源限制进行自动扩展

这种方法基于通过监测机制收集的实时服务指标。一般来说，资源调整方法需要基于CPU、内存或机器磁盘来进行决策。这也可以通过查看服务实例本身收集的统计信息（如堆内存使用情况）来完成。

当机器的CPU利用率超过60%时，一个典型的策略是新增另外一个实例，如图11-1所示。同样，如果堆内存大小超出了一定的阈值，我们也可以添加一个新的实例。当资源利用率低于设定的阈值时，缩小计算容量也是一样的，可以通过逐渐停止服务器来完成。

在典型的生产场景中，创建附加服务不是在首次发生超过阈值时完成的。最合适的方法是定义一个滑动窗口或等待期。

以下是一些常见的例子。

·一个响应滑动窗口的例子是，设置了60%的响应时间，当一个特定的事务总是超过设定的阈值为60s的采样窗口，那么就增加服务实例。

图11-1 根据资源限制进行自动扩展

·在CPU滑动窗口中，如果CPU利用率一直超过70%，并超过阈值为5min的滑动窗口，那么就创建一个新的实例。

·例外滑动窗口的例子是，80%的事务在阈值60s的滑动窗口，或者有10个因连续执行导致的特定的系统异常（例如，由于耗尽线程池导致的连接超时），在这种情况下，就创建一个新的服务实例。

在很多情况下，我们会设定一个比实际预期更低的门槛。例如，不是将CPU利用率阈值设置为80%，而是将其设置为60%，这样，系统在停止响应之前有足够的时间来启动一个实例。

同样，当缩小规模时，我们使用比实际更低的阈值。例如，我们将使用40%的CPU利用率而不是60%。这让我们有一个冷静的时期，以便在关闭时不会有任何资源竞争来影响关闭实例。

基于资源的缩放也适用于服务级别的参数，如服务吞吐量、延迟、应用程序线程池、连接池等。这也同样适用于应用程序级别的参数。

2.根据特定时间段进行自动扩展

根据特定时间段进行自动扩展是指基于一天、一个月或一年中的特定时段来扩展服务以处理季节性或业务高峰的一种方法。例如，在“双11”期间，各大电商网站都会迎来全年交易量的高峰，而在平时，交易数量相对而言就没有那么多。在这种情况下，服务根据时间段来自动调整以满足需求。图11-2所示为根据特定时间段来进行自动扩展。

图11-2 根据特定时间段进行自动扩展

又比如，很多的OA系统，在白天的工作时间使用的人数较多，而在夜间，就基本上没有人用。那么，这种场景就非常适合将工作时间作为自动扩展的基准。

3.根据消息队列的长度进行自动扩展

当微服务基于异步通信时，根据消息队列的长度进行动扩展是特别有用的。如图11-3所示，在这种方法中，当队列中的消息超出一定的阈值时，新的消费者就被自动添加。

这种方法是基于竞争的消费模式。在这种情况下，一个实例池被用来消费消息。根据消息阈值，添加新实例以消耗额外的消息。

4.根据业务参数进行扩展

根据业务参数进行扩展是指，添加实例是基于某些业务参数的，例如，在处理销售结算交易之前就扩展一个新实例。这样，一旦监控服务收到预先配置的业务事件，就会新增一个新的实例，以处理预期到来的大量交易。这样就做到了根据业务规则来进行细化控制。

图11-3 根据消息队列的长度进行自动扩展

如图11-4所示，在这种方法中，接收到有特定的业务参数时，新的实例会被自动添加。

图11-4 根据业务参数进行扩展

5.根据预测进行扩展

根据预测进行扩展是一种新型的自动扩展方式，与传统的基于实时指标的自动扩展有着非常大的不同。预测引擎将获取多种输入，例如历史信息、当前趋势等来预测可能的事务模式。自动扩展是基于这些预测来完成的。预测性自动扩展有助于避免硬编码规则和时间窗口。相反，系统可以自动预测这样的时间窗口。在更复杂的部署中，预测分析可以使用认知计算机制来进行预测。

在突发流量高峰的情况下，传统的自动扩展可能无济于事。在自动扩展组件对这种情况做出反应之前，这个高峰就会对系统造成不可逆的损害。而预测系统可以理解这些情景并在实际发生之前预测到它们。

Netflix Scryer就是这样一个可以预先预测资源需求的系统的例子。

 高可用

计算机的高可用性是指计算机平均能够正常运行多长时间才发生一次故障。计算机的可用性越高，平均无故障时间越长。

HP、IBM、SUN等小型机以上档次的服务器中，单机往往具有比较高的可用性，性能要求也极其苛刻。它们的主要特色在于年宕机时间只有几小时，所以又被统称为z系列。但即便是上述性能要求最苛刻的计算机，也无法保证不出故障。集中式的系统的一个最大的问题在于，就是不出问题还好，一出问题，就会造成单点故障，所有功能就不能正常工作了，即所谓的“一荣俱荣，一损俱损”。由于集中式的系统相关的技术只被少数厂商掌握，个人要对这些系统进行扩展和升级往往也比较麻烦，一般的企业级应用很少会用到集中式系统。

而分布式系统恰恰相反。分布式系统是通过中间软件来对现有计算机的硬件能力和相应的软件功能进行重新配置和整合。它是一种多处理器的计算机系统，各处理器通过网络互连构成统一的系统。系统采用分布式计算结构，即把原来系统内中央处理器处理的任务分散给相应的处理器，实现不同功能的各个处理器相互协调，共享系统的外设与软件。

这样就加快了系统的处理速度，简化了主机的逻辑结构。它甚至不需要很高的配置，一些低配置“退休”下来的机器也能被重新纳入分布式系统中使用，这样无疑就降低了硬件成本，而且还易于维护。同时，分布式系统往往由多个主机组成，任何一台主机宕机都不影响整体系统的使用，所以分布式系统的可用性往往比较高。

基于Cloud Native开发的应用，则天然具备了分布式系统的优点。

Cloud Native中的应用往往被拆分为多个服务（微服务），这些微服务往往又会部署为多个服务实例，并通过负载均衡器来进行协调。使用Cloud Native部署多个服务实例，具有以下优势。

·水平扩展计算能力。通过调整服务的实例数，可以水平扩展计算能力，比如，当处于业务高峰时段，就增加服务的实例，否则，就减少服务的实例。

·确保服务始终可用。其中，某一个实例不可用，则负载均衡器将流量切换到了其他可用的实例上。

·提升可用性。理论上，服务的实例数越多，可用性就越强。举例来说，单个实例的可用性是98%，那么，如果是3个实例所组成的集群，则可用性变为了99.9992%（1-2%×2%×2%）。

 敏捷

在开发和运维过程中，我们常常采用敏捷来作为指导思想。敏捷思想迫使公司调整应用的架构，朝着分布式系统、微服务架构转变，从而使软件的开发速度更快，故障风险更小。

·Cloud Native则使得这一切变得更加简单。Cloud Native构建了“开发——测试——部署——发布”的自动流水线，让产品可以第一时间交付给用户。

·Cloud Native自动化的运维方式，则解放了手工操作，避免了不必要的人工错误。

简言之，Cloud Native确保了软件通过不断重组其开发流程，从而可以更快地交付软件项目并将应用程序部署到生产环境中，最终得到正向的反馈。

云优先

Cloud Native在项目设计时，采用以云架构优先的应用开发模式。

具体采用何种云的方式，业界并没有具体的规定，项目组可以根据自身的情况来选型。比如，在一个大型互联网公司，往往自己有能力去构建属于自己的私有云。这种私有云可以是从最底层的IaaS开始，继而实现PaaS以及SaaS。公司内部项目组可以共享这些私有云所带来的便利。

对于小公司或者个人开发者而言，由于并没有这么多的资金和技术来实现私有云，则云供应商所提供的公有云服务是不二之选。

总结起来，IaaS、PaaS及SaaS三者的关系可以用图11-5表示。

图11-5 IaaS、PaaS及SaaS三者的关系

·IaaS：包含云IT的基本构建块，通常提供对联网功能、计算机（虚拟或专用硬件）以及数据存储空间的访问。IaaS提供最高等级的灵活性和对IT资源的管理控制，其机制与现今众多IT部门和开发人员所熟悉的现有IT资源最为接近。

·PaaS：消除了组织对底层基础设施（一般是硬件和操作系统）的管理需要，可以将更多精力放在应用程序的部署和管理上面。这有助于提高效率，因为不用操心资源购置、容量规划、软件维护、补丁安装或任何与应用程序运行有关的不能产生价值的繁重工作。

·SaaS：提供一种完善的产品，其运行和管理皆由服务提供商负责。通常人们所说的软件即服务指的是终端用户应用程序。使用SaaS产品时，服务的维护和底层基础设施的管理都不用操心，你只需要考虑怎样使用SaaS软件。SaaS的常见应用是基于Web的电子邮件，在这种应用场景中，你可以收发电子邮件而不用管理电子邮件产品的功能添加，也不需要维护电子邮件程序所运行的服务器和操作系统。

不管是公有云还是私有云，在开发应用时，采用Cloud Native架构，使得应用能够更快更方便地部署到云上。Cloud Native已经帮你考虑了部署到云上的诸多挑战，如下。

·应用如何拆分为微服务？

·微服务的颗粒度如何把握？

·服务之间如何来实现相互发现？

·服务间的通信方式？

·如何进行测试？

·如何确保安全？

·如何实现数据的集成？

·如何实现任务的自动化调度？

·如何部署、发布应用？

……