名为“原生”，实则“排异”——有状态服务请对云原生say no

  云原生，顾名思义，应该是指某软件或服务专为在云上使用而设计。然而，自这个词诞生以来，几乎没有什么有状态服务真正为了云而“原生”。恰恰相反，其使用成本往往比在普通服务器上部署高出许多倍。 这实在太可笑了。云本来的目的是降本增效，但时至今日，“增效”暂且不论，“降本”已像一句空话。这让从业人员不禁反思：云原生，究竟是进步还是倒退？   要回答这个问题，我们应该用数据说话：同样的价格，更好的表现；或者同样的表现，更低的价格，才能叫进步。否则就是倒退。 而目前的现状是：当有状态服务遵循云原生的方式部署在云上，既没有好的表现，也没有低的价格，那这种方式不仅不配谈“云原生”，反倒应该改叫“云排异”！

云计算的本质

  简而言之，云厂商购买了大量服务器，以互联网为媒介，用租赁的方式为客户提供按需付费的资源租赁业务，也就是“弹性”。 那么这种“弹性”对用户意味着什么呢？为了便于理解，我们可以用一个简单的出行问题来类比一下：大家如何解决日常出行呢？总结一下无外乎三种方式：

1. 买车。
2. 租车。
3. 打车。

  这三种方案无所谓高下，如何选择取决于每个人的实际情况。如果长时间用车频率高，资金充裕，个性化要求高，那么方案 1 是很好的选择。如果大部分时间不用车，偶尔有长时间用车需求，那么很多人会选择方案 2，成本低，取用方便。如果仅偶尔用车，或者钱不凑手，那么方案 3 则是上佳之选。   从成本角度来看，方案 3 虽然总成本低，但单次使用成本却是最高的。因为我们非常清楚，出行平台归根结底也是一家公司，他们要搭建平台，配备大量工作人员，购买或租用车辆，培训司机，负责车辆维护保养，为出行中发生的一切意外事件买单等等。所以我们为单次出行所付出的成本里还包含了平台的运营成本和利润，而这个费用一定高于方案 1 的单次成本。 同样的，云厂商也是如此。他们并不是不食人间烟火的存在，只是一个购买长期资产，提供短期租赁业务的公司。他们也要从硬件厂商那里购买 CPU、内存、硬盘等硬件组成服务器，然后放在一个超大规模的数据中心里，通过一系列软件管理后对用户出租存储和算力。   除了硬件成本，云厂商还要承担各种管理成本，再加上厂商的盈利空间，所以云计算不仅不能让算力变便宜，反而会让算力变得更贵。 因此，云并没有什么特别的地方，唯一能让用户切实感受到“便宜”的方式就是为用户提供“弹性”：用的时候付出比之前单次使用高一些的费用，但不用的时候就把资源释放掉，算下来总成本是降低的。 但是“云原生”真的能利用好“弹性”吗？

什么是“云原生”

  “云原生”的英文是 Cloud-Native，是一个叫 CNCF 的组织提出的，这个组织的介绍如下：

  参考 Official Link

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

  所以 Cloud-Native 只是一个保证软件可以部署到容器里的技术。 “云原生”对于无状态服务来说，确实可以提高可用性，甚至降低成本。但对于有状态的服务来说，情况则完全不同。

有状态服务真的适合云原生吗？

  对于数据仓库或数据库这种有状态服务，需要 Kubernetes 里提供的 StatefulSets 和 Persistent Volumes 来实现 K8s 化的部署。但在云服务上，persistent volumes 的选择其实不多，比如在 AWS 上只有 EBS 或 EFS 可选。

  参考 AWS 文档， 使用 EBS 后，总成本一定比部署在云下的同样软件高数倍。可以断言，直接使用 EBS 的有状态服务完全不适合云原生。

  除了 EBS 的问题，还有其他问题吗？ 当然有，最主要的就是数据类服务的“云排异”架构问题。

  传统的数据类服务基于单机系统的分布式改造，不可避免地带着旧时代的印记：

1. Share-nothing，追求本地计算。
2. 追求单机资源利用率而不是伸缩资源的效率。

  这两点互为因果：因为单机资源利用率高，所以尽量就近计算；因为就近计算，就需要挖掘本地资源利用率。然而归根结底还是网络带宽太窄。因此，就近计算、尽量提高资源利用率都是不得已的选择。即使不使用 EBS，就近计算也是把存储和计算强行绑定，经常造成资源错配，或不够，或浪费。

架构复杂，资源浪费

1. 这些有状态服务大多按照互联网公司的需求设计，遵循 KISS 原则，追求架构上角色的单一性。例如 proxy，query node，meta server 是完全分开的，但这本身就会提高服务器和运维成本。
2. 因为架构复杂，服务间相互依赖，导致整体规模的伸缩难度更高。
3. Meta Data Server 作为整个系统的核心服务，直接影响到其他所有服务的可用性。因此通常使用大内存、强 IO、高网络性能的 3-5 台服务器，对于中小客户来说，这几台高性能服务器的成本已经高得不可接受。

有了这些天生的“基因缺陷”，所谓的“云原生”有如下的“云排异”产品表现也就不足为奇了：

• 用户要先会算命

  选择虚拟机的大小要根据存储数据规模、数据增长速度、工作负载来判断。对用户来说，首先你不能是青铜，得多多少少懂点嘛。但即便你是王者也没用，因为最少也要按照业务峰值去做准备。可是峰值究竟是多少呢？只能靠掐指一算。最惨的是，即使峰值算对了，实际使用中能达到峰值的时间又有多少呢？总之，要么无法流畅使用，要么极为浪费。

1. 天价账单伤不起

  因为无法利用云的弹性，就等于你把出行平台的运营车辆包了，停在自己家停车位里天天用，几个月下来，花的钱比买辆车都贵。所以云排异的结果就是贵、很贵、非常贵。月底财务拿账单给你，你就会知道什么叫真正的心如刀绞。

3. 智能得靠人工保证

  云计算推荐使用 IaC(Infrastructure as Code)来分配资源，但是由于“云排异”的先天缺陷，即使分配了资源，服务也不能立即生效。为了保证高可用，需要人工介入，在用户到达之前完成伸缩。可以说，有多少人工，才能有多少智能。

4. 花钱买罪受

  当然，不差钱的老板大有人在，如果一个问题花钱就能解决，那怕什么呢？虽然 20w 的包和 20 块的包都能装东西，但前者还有个造型上的作用，咱主打的就是一个效果好。但已经“云排异”了，效果真的能好吗？

最后让我们看看“云排异”导致的症状吧：

• 云上的大部分资源无持久性保证，也就是说故障迁移后，数据会丢失。
• 虽然虚拟化技术已发展多年，但 VM 还是无法根除 noisy neighbor 的干扰，它的性能不如同样配置的物理服务器稳定。
• 云服务本质是一个共享的大数据中心，如果用户没有进行正确的安全配置，数据和服务就相当于裸奔。这都是云计算带来的成本。

因此，云原生之于有状态服务可真是又贵、又差、又麻烦。看到这里，你是不是想掀桌了？要这劳什子有什么用？难道有状态服务就不能跑在云上吗？ 各位看官稍安勿躁，当然可以，比如不妨看下面的

用 “云优先” 来替代“云原生”

是的，我们提出了一个最适合云的架构准则，我们叫它云优先.

针对名为“云原生”实则“云排异”所遇到的种种困境，“云优先”架构给出了另一个真正可行的解决思路。

1. 存储解决方案：“云优先“倡导使用对象存储而不是传统的弹性块存储（EBS）。对象存储具有更高的吞吐量、自动分层和按需付费等优势，使其更具成本效益和可扩展性。
2. 云基础设施服务：与依赖部署在虚拟机（VM）上的开源软件不同，”云优先“ 建议利用云基础设施服务，如消息队列、负载均衡和密钥管理服务。这种做法确保了更高的可用性、耐久性，并消除了单点故障。
3. 身份和访问管理（IAM）：IAM 被强调为管理权限的主要方法，与传统方法（如密码或访问密钥）相比，提供了更高的安全性、运营效率、合规性和可扩展性。
4. 基础架构即代码（IaC）：“云优先”倡导使用 IaC 技术部署，在运行期根据工作负载需求动态分配资源。
5. 函数计算：“云优先”鼓励使用函数计算而非虚拟机，将云计算提供的虚拟机视为成本更高、性能更高的函数计算。函数计算尤其适合具有显著变化的工作负载。

总之，与“云原生”架构不同，“云优先”架构专注于发挥云计算的“弹性”，而尽量摒弃那些模拟传统计算资源的组件。

“云优先” 架构的实践过程中，会遇到一些新的挑战：按需等比例分配资源、最大化利用网络带宽、将本地存储视为/tmp，以及最大程度减少资源占用时间。所有这些选择都是为了优化账单，这与传统服务器内的软件设计实践都是截然不同的。

综上，“云优先”不是一个渐进式的设计准则，而是一个几乎要求易筋洗髓的架构规范。实践它的过程中，意味着开发者要抛弃大量的开源项目代码、依赖库、固有经验，甚至是脑中的技术直觉。 回溯软件开发范式的变化史，软件始终在适配硬件的发展。比如千禧年时，大型机被微机集群所替代，云原生携容器技术的分布式架构席卷业界。到了眼下，云计算普遍拥有了高性能网络，伸缩性成为了云最有价值的特性，有状态服务无法遵循“云原生”架构来获益，只能通过“云优先”架构来实现性价比的提升，来追求真正意义的“降本增效”。 我们基于“云优先”架构设计了新时代的全能数仓 ClapDB，我们会通过一系列内容来分享 ClapDB 的特别之处。敬请期待。