公有云已经进入下半场
公有云的发展已经进入下半场，无论是国外还是国内，市场格局已经基本确定，后来者很难再有机会打破现有的格局。纵观国内市场，阿里云一家独大，其他厂商都还在奋起直追，艰难的维持着自己的市场份额。虽然最近两年，不断有大的厂商宣布进军公有云领域，但我认为留给后来者的时间并不多了。公有云是一个强者恒强的行业，随着头部厂商的成熟，厂商锁定(vendor-lock)的现象会越来越凸显，进而越来越多的用户会投入头部厂商的怀抱。虽然，后来者可以在一些细分领域找到某些差异化的优势，但整体格局不会太多的影响。
相信排名靠后的公有云厂商都在思考一件事，我如何进行差异化的竞争？其实这是很难的一个问题，差异化竞争归根结底还是要建立在技术门槛之上，靠其他优势带来的差异化只能是短期的。技术门槛的建立不是一日之功，需要持续的投入和战略级别的支持，所以中小厂商是很难有机会“超车”的，只能争取头部厂商无暇顾及的领域，得以短暂的喘息。
差异化竞争除了在产品、技术方面的竞争，还有一个很容易让大家忽略但又十分重要的点，那就是公有云的计费模式。本人作为一个公有云产生的参与者与亲历者，想谈谈个人对公有云计费的看法。
计费的重要性
不知道大家再刚接触云计算的时候是否听说过这样一句话：
云计算会像现在的水和电一样。
这是非常形象的一句话，也是对云计算最终形态的一种展望。但是大家有没有想过水和电是怎样收费的？每个月结束的时候（或者下个月开始的时候）有人上门来抄水表电表，然后根据你实际的使用量把账单给你，最后你根据账单付钱就可以了。
云计算里面有一个很重要的特性，就是Pay As You Go，意思是按你的实际使用量来付费。那现在有哪家云计算厂商做到这一点了呢？现实的答案是：None，没有一家云厂商做到了。你可能会疑惑，难道云厂商的”按量付费“不是按用户的使用量付费吗？还真的不是。用户去公有云厂商买一台云主机，云厂商会提供各种类型规格的主机供你选择，然后你根据自己”预期“的需要选择一台。大的云厂商可能会提供非常多种类的云主机，按用户的使用场景进行细分，是的云主机能更加贴合用户的真实场景，但这样做也仅仅是减少了你花的”冤枉钱“而已。你购买的绝大部分云服务以低负载的模式运行，而你用不到的那部分资源被无情的浪费了。当然，这种浪费是针对用户而言的，云厂商可不会因为你没有完全使用云主机而把多余的部分退还给你。这种现象在计算资源和带宽资源方面表现的尤为突出，存储相对而言要好一点。
现在情况相对来说要好点了，大型的云厂商开始提供”竞价型实例“来缓解这一现象。用户可以把自己多余的计算能力进行公开的售卖，而计算能力不足的用户也可从”市场“上买到价格合理的计算资源。这有点像股票市场，让用户来决定资源的价格，当然，这个市场也是受云厂商控制的。另外，越来越多的厂商提供”按秒计费“，也就是计费的时间粒度可以精确到”秒“，但这仅仅是时间维度的贴合，资源的实际使用量还是不会影响你的账单。也许，Serverless才是最终的计算形态，相对其他的计算形式，它可以更加接近Pay As You Go的宣言！本人也十分看好Serverless的发展。
但短期内，云主机并不会消亡，容器技术也在逐步成熟，如何调和用户对资源的诉求和成本控制之间的矛盾将成为公有云厂商一个有利的竞争点。我们知道，Dropbox因为成本问题，从AWS上迁移出来，自建数据中心，从其官方的说法中，它减少了巨大的成本。这是公有云厂商都会面临的一个问题，当用户使用的资源量达到一定的级别，它会发现自建的成本会比使用公有云的成本更低，而公有云厂商无法给出一个双方都能接受而又不扰乱市场的定价，最终只能一拍两散。实际上，这对双方来说损失都是很大的，因为”上云“需要成本，而”下云“更需要成本。造成这种结果的原因无疑是多方面的，其中的一个原因就是云厂商无法准确的评估用户的资源使用情况，而呆板的计费策略造成用户为大量的浪费资源而付费。
云计算发展到今天，很多技术已经相当成熟，各家云厂商的产品也越来越趋同。在产品同质化如此严重的情况下，提高云平台整体的”软实力“就相当重要。而公有云的计费无疑是”软实力“中最重要的一个因素。不得不承认，无论用户是创业公司还是像Dropbox和Netflix这样的明星公司，成本控制都是相当重要的一环。而产品的计费策略直接与成本挂钩。降价、打折、促销只能是短期吸引用户的手段，最为核心的竞争力在于产品的计费模式能多大限度的贴合用户的使用场景。一个好的计费策略可以极大的提高产品的竞争力，毕竟这将直接关系用户的钱。
售卖形式与产品定价
IaaS、PaaS和SaaS的云服务的售卖形式有着巨大的差别，而且越接近SaaS形态，产品的售卖形式越特化。云服务的产品和负责人需要根据自身产品的特性，谨慎的思考产品的售卖形式。因为公有云的产品与其他的互联网产品有着一个显著的区别，那就是用户的使用方式将直接影到产品本身的开发。云服务的用户基本上都是高端用户，主要面向程序员、SA、PE等软件开发运维人员，他们将直接使用产品提供的OpenAPI、SDK，这就导致了使用方式与产品特性的深度耦合，从而使得云产品在后期的迭代过程中必须考虑向前兼容。售卖形式是云服务产品形态的重要一环，前期的小心设计大大降低后期产品在迭代过程中的兼容负担。我相信谁也不愿意在产品正式售卖之后，发现售卖形式完全错了，而已经在使用云产品的用户会让你大为头疼。
IaaS产品的售卖形式现阶段已经比较成熟，计算、存储、网络都有着比较标准的售卖模式，这些售卖形式已经被用户所接受，并形成了业界共识。IaaS产品基本上都是按资源的“占用量”来进行售卖的，但“占用量”这里面大有学问，各个云厂商都有着自己的超售比，而超售比是厂商的一个机密数据，用户永远不会知道自己的云主机运行在一个超售比多少的物理机上。前面也介绍过，按资源的“占用量”来售卖会造成用户为没有使用到的资源付费，最终得原因在于厂商无法精确得评估用户所需的计算资源以及能在获取短时间内调度大量计算资源的能力。所以云厂商最终把这个问题抛给了用户，让用户决定自己需要的计算资源。但这并没有解决问题，这仅仅是对厂商友好的一种计费方式而已。然而用户似乎比较满意现在的售卖模式，可能因为人都有“占有欲”吧，当然你需要为这种“占用”付出代价。
相比于IaaS，PaaS产品的售卖形式开始变得复杂了。不同于计算、存储、网络独立计费，PaaS产品“有机地”将三类资源进行组合，并根据产品本身的特性来提供“增值业务”。比如，RDS会提供高可用版或者集群版，除了底层独立占用几台云主机外，还会提供高可用、定时备份、数据操作、水平垂直扩容等服务。PaaS的核心价值也体现在这种高附加值的服务上。如果PaaS使用起来不方便，经常出问题，用户购买的PaaS服务的意义又在哪里呢？所以PaaS的定价一定不是在于底层资源的占用了，当然这是一个考量因素，但更为重要是PaaS产品提供的高附加值服务，这也是用户购买PaaS产品的初衷。一种简单的售卖形式就是将这些服务和底层资源全部打包在一起进行售卖，因为这些服务往往是建立在具体实例之上的。这种做法的一个明显缺点在于，这些高附加值的服务与底层资源绑定了，导致了这些服务无法独立的售卖，从而降低了整体的灵活度。可能用户仅仅需要RDS的高可用特性，而无须定时备份等功能，是否可以考虑降低用户的购买成本呢？
SaaS与PaaS的一个共同点在于他们都对用户屏蔽了底层资源。也许用户在使用PaaS服务的过程中还能零星的感知到底层资源的存在，但在SaaS服务中他们就已经完全感知不到底层的基础设施了。一个有趣的问题，大家是否认知的思考过，AWS的S3到底是IaaS、PaaS还是SaaS呢？相信不同的人会有不同的看法。随着云计算的成熟，必将会出现越来越多的难以简单划分的服务出现。因为SaaS产品已经完全对用户屏蔽了资源占用的概念，那么它的售卖形式肯定不再是以资源的维度来定价，而应该从SaaS产品本身提供的功能出发来定价。例如，某个搜索服务产品，它的主体功能提供了数据索引与搜索，那么它的售卖形式必然会以索引和搜索的数量来进行售卖。相比于IaaS和PaaS，SaaS服务更容易达到“Pay As You Go”的理念。令人遗憾的是，某些SaaS产品出于简单的需要，而仅仅将整个SaaS产品打包售卖，又回归到了以资源占用为维度的老路子上，这实际上是本末倒置的。
我一直觉得给产品定价是一项极具挑战的任务，因为涉及到的因素实在太多了。超售比、成本、调度策略、市场环境、产品特性等诸多因素都会影响产品最终的价格，而这些因素很难有一个简单的公司来调和。本人在这方面也没有多少经验，不敢妄言。但我还是建议厂商根据自己的实际情况来考虑自身的定价策略。大的厂商一定要有自己的定价逻辑，针对不同的产品线有不同的定价基准，而具体的产品可以在这个基准之上进行调节。而小的厂商尽量参考大厂商的定价逻辑，这有利于形成差异化的竞争力。但总体来说，产品定价还是一项十分复杂的工作，有能力的厂商需要建立自己的定价团队。好的定价策略会让你赢在起跑线上。
结算方式与计费策略
国内与国外的云计算厂商在结算方式有一个明显的区别，国外的厂商更偏向于后付费，而国内的厂商更喜欢预付费。这可能与国内外的使用习惯，信用环境有关系，但这已经是一个既定的事实。国内的预付费方式无疑加重了计费系统的负担，因为预付费的收费逻辑与后付费的逻辑是完全不同的，况且真实的环境是两种方式的组合。
预付费的逻辑是期望能尽早地锁定用户，把钱先收进来，但先收的钱并不能纳入到厂商当前地实收中，因为大部分是未来预期地收入。这种做法的一个巨大的好处在于将用户锁定，一旦用户已经支付了未来的使用费用，那么他潜在的心智更期望能物尽其用，反过来进一步增加了用户粘性。国内的厂商基本上都极力推崇这种方式，甚至不惜以高折扣的方式来补贴用户，也希望能锁定用户。这实际上是技术上不成熟的无奈之举。
实际上，后付费是最符合”Pay As You Go”的理念的。用户只需要为他们使用的资源付费，如果还没开始使用，那有何来付费之说呢？排除国内外的差异因素，我觉得AWS一开始就走在了正确的道路上。虽然AWS也支持预留实例，但这仅仅是一种获取折扣的方式，大部分产品都是在使用后根据账单来结算的。后付费的另外一个优势在于它更有利于云产品与计费系统的解耦，因为用户无需在使用之前完成下单、支付与产品无关的交易行为。
采用预付费还是后付费，又或者是两者的组合，还是要根据产品本身的特性出发。我看到一些很复杂的产品，它实际上更加适合后付费模型，而偏偏采用预付费方式，造成用户在购买上面遇到了很多问题。一个简单有效的经验是，如果产品本身的构成比较简单，采用任何一种付费方式或者组合都是可以的；反之，如果产品的构成比较复杂，建议使用后付费。产品构成是指用户可感知的产品元素，举个Redis的例子，一个高可用版的Redis Sentinel可能由3台Sentinel和一对Master-Slave节点构成，但对用户暴露的仅仅是3个Sentinel的链接地址，那么用户感知到的产品构成是比较简单的。另外一个例子，比如托管型的ELK服务，该服务对用户暴露了ElasticSearch、LogStash和Kibana，产品构成就比较复杂了，如果采用预付费的收费模型，那么该服务在扩展时就会与订单与计费系统产生大量的交互行为，降低了用户体验。
谈到计费策略，可能让人首先想到的是“按量计费”、“包年包月”等词汇，这些词汇是厂商为了更好的进行销售而形成的一套特定用语。我们先抛开这些让人眼花缭乱的名词，思考一下为什么需要计费？如果用户选择后付费，那么我们需要记录用户资源的使用情况，然后根据产品的计费模型计算出用户的账单，这是计费最核心的功能。那么如果用户选择预付费呢？当然我们不需要计费了。
现实的情况是复杂的。某些产品的计费模型十分灵活，可以部分预付费部分后付费，那么就要求计费策略可以下沉到计费项这个级别。一个比较典型的例子就是，经典云主机可能在创建时获得一个公网IP，整个云主机可以包年包月购买，而公网IP部分又可以按流量计费。先不看技术上如何实现，需求层面是否合理。现在的一个趋势是，云产品越做越大，越做越细，越做越复杂，如果再将整个云服务打包卖个用户已经跟不上市场的节奏了。一个云服务的构成可能需要多种资源的配合才能完成，但是资源之间的配比和售卖形式是可以不一样的，按照资源粒度去售卖可以更加贴合现实的使用场景，降低用户的成本。总体来说，需求是合理的，也是一个必然的趋势。计费策略可以很灵活，但一定要形成统一的标准。只有在统一的计费模型上演化，系统的复杂度才可控，产品也能把握整体的一个节奏。
技术实现
不得不承认，要做好公有云的计费非常难，这种难度在于对公有云行业的深入理解、对云服务产品计费模型的准确把握以及计费系统本身的非功能性要求。我分享一些此方面的一些经验。
抽象化与建模
最开始的时候，计费系统并没有将云服务产品抽象化。在前期产品不多的情况下，我们还能针对一个个具体的产品编程，理解各个云产品的计费逻辑。但随着业务的加速发展，这种方式已经跟不上业务的要求了。我们意识到必须把产品的计费模型抽象化出来，我们根据这个抽象化的模型去编程，这样将大大提高系统的扩展性。后期的重构过程中，我们也确实是这么做的，并且达到了我们的预期效果。但是随着一些SaaS型或者复杂PaaS型产品的出现，我们第一版的抽象化模型已经很难适应了。那是不是我们需要进一步抽象化呢？其实不然。抽象化是有代价，当你提高了抽象化等级，结果只有一两个产品受益，大部分产品没有从中得到任何好处，其实这已经是过度抽象化了。解决这个问题的一个方式就是建立一个不同的模型。前期我们总想着只用一个模型就能解决所有产品的计费，实际上这总想法太天真了。每个产品的计费策略和模型都不一样，SaaS型产品和IaaS产品的计费方式差异巨大，如果想用一个模型搞定所有问题，只能得到一个难以理解和维护、需要处处小心、高度复杂的模型。所以，如果发现某些产品的计费方式与其他产品的差异巨大，去建立另外一个模型吧！
定好规则
计费系统很难做的原因之一就在于很难建立一个统一的计费模型。有人可能会说，使用规则引擎吧，还有流程引擎，但是这些技术都是建立在你有着一个相对统一的模型基础之上的，如果没有计费模型支持，那么整个系统只能是空中楼阁，就算能正常运行，也不能灵活扩展。
当你的系统为几十种其他系统服务时，定好规则就十分必要了，这也符合”中台“的思想。如果你建立了一种模型可以适应于多种计费场景，那么剩下的就是为这个模型定好规则，推动业务方按规则接入就行。在这个过程中，可能会遇到很大的阻力（可能有些业务方比较强势），但你也要坚持自己的原则，不要轻易动摇，更不要专门为单独的一两个业务去适配。因为一旦你这么做了，那就是噩梦的开始。
尽量解耦
我一直在谈计费，但这里的计费其实包含了云服务完整的售卖过程，涵盖订单、优化、支付、计费、结算完整的售卖链路。每一步都可以独立拉出一个系统来做，也建议独立系统来做。如果人员不够，可以考虑先将系统拆分，由不同的人来维护几个模块。现在微服务架构十分流行，可以考虑使用微服务架构来解耦系统。除了系统内部的耦合，我们也需要交互流程上尽量解耦。AWS在这方面是有天然优势的，因为它主推后付费的模式，云服务和计费系统前台界面上基本没有交互过程。减少与云服务的交互过程，将极大地降低系统地复杂度，提高整体地稳定性，毕竟计费系统要服务于整个云平台。
总而言之，公有云计费很重要，也很复杂。做好公有云的计费需要投入大量的资源，更需要丰富的经验。现阶段的计费模式还存在诸多不合理的地方，还有很多可改进的空间。预计随着公有云的进一步发展，可能会逐渐淘汰目前计费方法，出现更多更灵活的计费模型。最终的发展方向肯定是实现”Pay As You Go“的终极理想！
