作者 | 汪志成

本文主要面向企业决策层。我会尽量用浅显的语言和简明的例子来表达主题。

在 2022 年，“云”早已不再是热词，似乎已经成了像水和电一样习以为常的基础设施。但技术的阳光还远远没有照亮世界的每一个角落，你，是否位于其中之一？

而今，云已不再是新潮，炒作已然落幕，浮躁已然平息。此刻，才是普通企业跟进的大好时机。

作为资深软件工程师，希望我的文章能为你的上云之路提供一些助力。

这些年，虽然已经被“云”这个词完成了信息轰炸，但是你是否认真地想过怎么上云？基于云的开发运维模式和传统的方案有何区别？不了解这些，上云就是一个盲目的跟风而已，既无法充分发挥出其价值，也无法在遇到挫折时明智地决定是坚持还是止损。

要想全面的认识云，可以从几个视角来看云对企业 IT 模式的影响。

一、新开发模式

云平台的出现，深刻地影响了开发模式。无论是技术选型、系统架构、研发组织架构还是基础设施，都要为上云做好准备。

对于上云的应用，微服务几乎是必然之选，因为云平台的基础功能之一就在于动态调配计算资源（CPU、内存等）。

我们知道，在一个应用中的不同部分，所需要的计算资源是不一样的。比如“查看商品”功能的使用频度通常远高于“支付订单”。如果使用传统的方式，把所有功能都放在一个运行单元中（即单体应用），那么就只能将其整体扩容（复制多份，负载共担）才能实现，这将浪费大量的计算资源。而微服务技术可以把使用频度不同的功能拆分成不同的运行单元，每个运行单元称之为一个微服务。比如当“查看商品”功能的使用频度很高时，就可以只对它所在的运行单元进行扩容；当使用频度降低时，就可以释放不再需要的运行单元，把计算资源释放回资源池。

但微服务也需要相应的技术储备。

微服务与架构

要想实现微服务，首先要解决的问题就是如何合理地设计系统架构。从“便于扩容”的目的出发来做架构设计是个很自然的想法，但这还远远不够。“便于扩容”在架构设计的术语中称为“延展性”或“弹性”。而在架构设计中，总是要在架构的各种属性之间做出一定的权衡和取舍，延展性也不例外。我们必须找到一种更加自然、更加科学的方式来确定架构中模块的弹性边界。

通常来说，对于长线项目，扩展性（也就是容易增加新功能）高于延展性。因为前者的成本主要在于程序员，而后者的成本主要在于硬件平台。当两者冲突的时候，除非延展性已经到了投入再多资源也没有效果的阶段，否则还是程序员方面的人力成本更高一些。

因此，我们可以遵循一个原则：在架构设计上优先考虑扩展性，扩展性满足要求的前提下，针对延展性做局部优化。比如，先针对扩展性设计一级模块，然后找出这个一级模块中对弹性要求较高的部分，单独提取成二级模块。

那么，如何实现扩展性优先的架构设计呢？

首先，我们要弄明白“扩展”的来源 —— 一个系统为什么会需要扩展呢？最简单直接的回答是“因为业务需求变了”。所以，我们得到了一个前提：“充分理解业务及其领域知识，包括业务及其领域知识的现状和发展趋势”。

然后，我们要想清楚“扩展”的成本来自哪里？为什么进行扩展会很昂贵？这有两方面的因素：技术上的和管理上的。

从技术上看，当业务需求发生变化时，就需要对现有代码进行调整。这种调整最好聚焦在一个较小的范围内，这样一来它所需的设计、开发、测试、部署等工作量都比较小。这个“较小的范围”，最好集中在一个或少数几个微服务。当然，也不要因此而设计过大的微服务，那样就会导致很多不相关的代码在变更时被迫“陪绑”。

从管理上看，当业务需求发生变化时，就需要和相关的开发团队进行沟通。在开发过程中，这些开发团队之间还需要互相沟通，而这些沟通都是额外的成本，当需要做的跨团队沟通很多时，这些成本就会出现非线性增长。

因此，我们应该得到这样一个架构：无论从技术视角看还是从管理视角看，这个架构都应该对齐到业务自身的本征架构。这样一来，只要业务的变化只会发生在局部，那么对代码的调整也只会发生在局部，对团队的影响也同样只会发生在局部。

所以，问题归结为一个：“如何准确的认识和表达业务自身的本征架构”。而答案也很简单：“交给专家”。让领域专家来识别并表达业务自身的领域知识，从这些领域知识中提炼出其本征架构。

架构、DDD 与演进式架构

然而，简单的答案往往意味着复杂的行动。领域专家在自身的业务领域固然是专家，但是往往也只懂其业务领域的一小部分，整合多位领域专家的知识，是一大难题。即使我们能整合，如何通过领域模型把它准确全面地表达出来又是一个更大的难题。因为业务专家不一定都有很强的逻辑性，如果没有受过专门的训练，很难驾驭和表达复杂的领域知识，更不用说大规模的领域知识了。那么，还有更大的难题吗？有！那就是长期维护这个领域模型。

前两个问题的答案就是“领域驱动设计”，也就是最近大火的 DDD；而后一个问题的答案是“演进式架构”。

“领域驱动设计”的基本思想，是让业务方面的领域专家和软件技术方面的架构师来共同梳理领域知识，以便建立一个容易被开发团队成员理解的领域模型。而演进式架构则是强调，不要把架构看做静态的、一成不变的产物，不要追求一步到位，而应该用各种手段来监测、守护它，提早发现架构问题的时机，降低发现和修正架构问题的成本。

这两个话题都很大，这里就不展开了。感兴趣的可以自己进一步研究。

二、新投资模式

在云生态下，大量采用按需付费模式。在这种模式下，基本上不需要多少前期投入 —— 用户量小的时候就少买资源，随着用户规模的提升，逐渐扩大投入即可。这样可以降低试验新商业应用的成本和风险。

按需付费通常又分为三种子模式：

按需付费模式

这种模式非常简单：边用边计费，随时停用随时停止计费。一般精确到小时或秒级（取决于资源类型）。但是，像流量这样的资源比较特殊，它的按需计费不是按小时或秒计费，而是按实际流量计费。

但是要注意，不同的资源的停用标准不一样，比如 ECS（相当于虚拟机）只要停止就会针对 CPU、内存等停止计费，但是挂载的云硬盘、IP 地址、包年包月带宽等仍然会继续计费。要想释放这些，就要专门把它们停用。

另外，由于运营成本的不同，所在可用区对计费，甚至开通的服务也有着显著影响。一般来说，发达地区的可用区比较贵，偏远地区则比较便宜。具体的选择要视多方面的因素而定，必要时可以先做一下测速。

按需计费类似于零售模式，因此单位费率通常都是最高的，只适合做一些短于一个月的试验性项目。

包年包月模式

相当于按需计费的批发模式。在按需计费的基础上，包年包月模式会提供一些额外的优惠。

但要注意，包年包月的流量是根据最大带宽档位进行逐月逐年计费的。对于流量很小的应用，这种方式的实际费用反倒会高于按需付费模式。因此，对于流量很小的应用，即使要长期运营，也可能要选择按需付费模式的流量。当然，对于大部分应用来说，包年包月总是要比按需付费便宜一些的。

在云平台里，包年包月模式和按需付费模式通常是可以互相转换的，因此在首次选择时也不必犹豫再三，因为费用差异没那么大，为此耽误商机就不值得了。

竞价计费模式

这是一种闲置资源拍卖模式。选择竞价计费时，你的出价并不是你的实际出价，而是你愿意为保留实例而出的最高价。平台会定期对竞拍者按出价进行排序，然后依次分配资源使用权，那些分配不到使用权的，就会自动被平台释放。

这就意味着，要用不确定性来换取优惠。因此，它的适用场景和前两种模式有着显著的差异。竞价计费模式通常用于一些随时可以启停的批处理任务，比如一些非紧急统计报表的生成任务。云平台会保证竞价计费的单价不会超过按需计费模式，可以放心尝试。

以华为云的 ECS 服务的报价为例（2022-12-06）：

当选择华北“乌兰察布”区的 c7.large.2 配置时（2vCPUs，内存 4GiB，CPU 型号 Intel Ice Lake，最大带宽 4 Gbit/s），包一个月的费用是 184.95 元/月，包一年的费用则是 2,129.50 元/年，相当于优惠了425.90 元。

如果选择按需付费模式，则为 0.4238 元/小时。折算到月（按 30 天算）就是 305.136 元。也就是说，只要按需付费超过 18 天，费用就已经和包月持平了。

华为云的“北京四区”开通了竞价计费模式，并且支持自动竞价模式，自动竞价会自动对标当前市场价格。自动竞价通常是比较划算的，否则也不会有用户选择。当然，有经验之后最好根据自己对服务中断的容忍度，自行设定竞标价格，以达到“恰好够用”的出价级别。

三、新运维模式

云平台会帮你完成服务器、网络等基础设施的运维，通过这种集约化的运维方式，可以省去全部硬件运维工作以及大部分系统运维工作。但是应用层的运维仍然只能由运维人员自己做。

不过，好在云平台基本上都提供了应用运维平台，比如华为云就提供了“应用管理与运维平台 ServiceStage”，它提供了应用开发、构建、发布、监控及运维等一站式解决方案。当运维任务比较重的时候，可以考虑按需采购此项服务。

如果预算有限，可以考虑基于开源软件来自行搭建，有的平台（比如华为云 CCE）提供了插件。比如：

• 用 ELK 来支持日志收集与分析工作，通过日志，可以对应用的运行状况进行剖析，定位并诊断错误，识别潜在威胁等。
• 用 Prometheus 对系统和应用的运维数据进行监控和预警，以便触发对特定运维事件的自动化处理。
• 用 Grafana 对运维监控数据进行可视化，以便让各个干系人可以凭直觉发现运维问题，主动提供不同力度的人为介入。

这些软件通常会搭配使用，但其自身需要有人维护，而且其整体性仍然不理想，对运维数据的挖掘也不够深入。

如果应用系统更加复杂，那就不能指望这些通用的应用运维平台了，而应该在应用系统的设计之初就直接把特有的运维需求包含进去。对于开源方案，可以更好地进行深度定制，不过需要的技术水平通常会比较高。对于云平台方案，由于进行了专门的 API 封装，通常可以更简单地进行定制，但是深度受限。

四、未曾设想的道路

云平台的意义，不仅仅在于代替了传统的开发方式和基础设施，更重要的是它打开了许多未曾设想的道路。比如：

不再自建数据库，而是直接使用云平台提供的数据库服务，这样一来，数据库本身的运维工作也交给云平台去“集约化”了。

对于流量波动巨大的系统，不需要再基于最大流量自建消息队列，而是把这部分容量交给云平台来统一调配。

对于像人工智能这样的“新兴”技术，不需要再自己搭建和运维，而是让云平台来搭建这些基础设施，自己只做应用层开发即可。甚至连应用层编码都不必做，而是直接使用云平台提供的可视化工具，由业务专家来进行分析和预测。

这种模式称为 PaaS（平台即服务）。

对于一些中小企业，甚至可以考虑不再自建应用软件，而是使用云平台提供的 CRM 等在线版软件，自己只需要在其中开一个租户即可。但是，如果涉及到商业机密数据，就必须找一个可信的提供商，保证自己的数据不会被软件的运营方泄露。非专业用户很难判断运营方的可靠性，只能靠运营方的商誉和运营记录来判断了。

不过，对于中小企业，除非自身非常有特色，否则通常不用过早担心数据泄露问题。等成长到一定级别，可以花钱请软件提供商进行私有化部署，把运营权限完全收归自己。甚至可以重新开发一套私有系统。

这种模式称为 SaaS（软件即服务）。

除此之外，还有一种更激进的 FaaS（函数即服务）模式。在这种模式下，应用开发者甚至都不必关心部署、运维等细节，只需要关心业务逻辑就可以了。不过，这部分的能力和方法论体系还不如 IaaS、SaaS、PaaS 那样成熟，因此可以做一些技术储备，但是要想落地还需要谨慎评估。

本文还远远不足以展现云对于商业的影响，甚至，都无法判断云还会有哪些新奇的玩法。正如前一节所说，无论从商业意义上还是技术意义上，云都向我们展现了一些未曾设想的道路。你，是否会成为某一条新道路的开拓者？让我们拭目以待！