万字长文：云原生底座之营造法式 | 平台供应商视角-第一部分

编者按：《100页ppt讲清楚云原生

作者介绍：

高磊(曾用花名世忠、胤禛) ，16年工作经验，原阿里巴巴、华为架构师，专注于云原生领域的产品规划设计以及技术架构。

21 世纪人类”繁荣昌盛”,人口持续增长的前提条件是有能够维持人类穿衣吃饭的资源同步增长。但是如此迅速的增长需要的不仅仅是土地的增长，因为土地的占有是有极限的，更需要更高的生产力，这便意味着生态的、技术的创新也需要与日俱增。因此，人口的快速增长必然伴随着技术令人眼花缭乱的翻新。在过去的 200 年间，创新再也不是孤立的、偶然的，而是普遍的、无所不在的。没有任何证据表明这种技术创新何时会被终结，事实是正好相反，21 世纪，创新的速度比任何时候都要快。”信息技术是经济增长的动因，也是经济增长的结果”。

现在业界已经不是谈论数字化转型或者数字化改革的话题，而是讨论如何实施数字化。对于消费者而言，例如我们已经不再更多使用纸币进行商品交易，而是用互联网第三方支付进行交易；对于生产领域的工厂而谈，不再以纯机械方式进行，而是由智能程序所控制的生产过程！这些都指向一个方向：更高效、更集约的生产力模式。

诚然，数字化仅仅依靠技术是不行的，它是体系化解决方案，涉及战略决策方式改革、组织管理方式变革、销售渠道和方式变革、运营方式变革、教育变革、技术变革等全方位的变革，如此庞大的体系，人们应该清晰地认识到技术是变革助推剂，而不是主燃料，技术是”为人民服务”，而不是反过来，到目前为止，还不可能找到一件人造物不是为人的需求服务的。

数字化话题过于庞大，我们这里聚焦在以云供应商角度来营造云原生技术产品的问题，云原生是数字化变革技术选择的一种，或者说更贴近现代方式的一种，而且是发展加快的一种，此文面向的阅读人群是市场产品人员、架构师或者CTO。面向云原生，本文会更加聚焦，同时从一个相对微观的视角来体会战术层面如何实现商业战略构想的问题，但同时云原生技术产品是一个巨大的技术生态体系，为了说明问题，因为云原生分布式操作系统产品是其他云原生产品的支撑基础，所以选择云原生分布式操作系统产品（后文统称为底座）作为本文的主题贯穿始终！

姑且假定都知道关于建筑的《营造法式》古著，但这里讲一种现代的软件营造法式，这个隐喻当中，便有这样的道理：房子不会以家具款式而建、家具也不会根据房子而设计、房子是给人住的。但是换成现代软件的营造，甚至于众多人不解如上类似之显而易见的含义，足见现代人也不比古代人聪明多少，过度依赖工具和经验，却不知道从何思考！

试思考以下情况，市面上有不少如此的底座产品，它约定必用 Sping cloud 之类来构建微服务，而其周边也必是 Zookeeper 之类而相互依存，认为将其周边依赖沉入平台中是很好的实践，理由是大部分企业所系者为 Spring cloud，所以可解决大部分的需求，这就如按家具造房子的思路如出一辙，家具一辈子不能换，要换连房子一起换了！

更有甚者将服务治理等认为是特定服务框架所规定的东西（服务治理必须长成 Spring Cloud 规定的样子），而非运维人员根据观察性所使用的稳定性运维工具，所以将 Spring Cloud 所设计的私有化服务治理工具放入平台供研发用户使用，除了因为研发人员不理解运维维度的问题所导致的参数配置困难问题外，Spring Cloud 服务治理组件接口一升级，平台也需要升级！老的应用如不是 Spring Cloud 的，还需要企业花钱改造为 Spring Cloud 的，再部署到平台之上！以上者还不是最严重之处，最严重的是这个思路：平台只是跑 Spring Cloud 的，我们只需营造了一个控制台就可以了！试问，用户主体是研发人员，研发人员对什么最有亲和？是界面？还是关心内部的能力呢？和裸体 Spring cloud 之间有什么差别和竞争力？到底解决企业什么核心问题？.....目前市场情况处于一种缺乏标准的时期，绝大部分客户企业还在摸索实践当中，这个时期非常容易被一个伪底座平台绑架，但是一旦清晰了，这些伪底座平台一定没有立足之地了。

比如某厂商的所谓云原生平台：

将某种特定服务框架的基础组件依赖和平台集成到一体，强制约定服务框架和模型，用房子规格规定家具规格，无法做到标准化，无法适应多种差异性交付环境。

很多平台提供商几乎全然不知所然，完全是从技术上考虑问题！回到房子隐喻，房子设计前，必思考这样几个问题：有没有企业有这样的需求？有没有市场？市场规模多大？市场趋势如何？谁会买这样的房子？房子应该建成什么样子的？这个房子如何保证比别人造得更好？如何建造这个房子？再绕回上面如图的底座视角，从技术手段这个结果反推要营造一个怎样平台的因是否可笑？但是实际情况是，很多平台提供商认为这种强制约定型底座确实解决了他们客户的问题，是的，没错！但是那是因为是平台提供商自己认为一切都以客户需求来做的。

所以会产生几个后果，其一，私有化部署方式很难复制，平台提供商需要强大的定制化支撑；其二，平台只考虑满足眼前的利益，随着客户业务的发展必导致底座升级，这种不稳态的设计，使得客户内生恐惧；其三，只是在原有的空间内优化，无法做出对生产力更高要求的平台，历史上有个很有趣的例子，汽车代替马车就是一则好的例子，客户需要的是更快的马车，如果供应侧不进行深入地思考，挖掘客户背后真正想要的是更快的交通工具这样的需求的话，估计我们现在还在使用再优化的马车作为交通工具！更不要说会诞生汽车这样一个产业了！

当然，纵使某平台提供商已经意识到平台不是这么按照一种应用框架（家具）去做的，但是又陷入伪云原生的怪坑里面去了，请阅读《100 页 PPT 讲清楚云原生》，先补补课甚为妥当。

底座，是为隐喻！君不见 Linux 可运行在多种硬件之上！君不见 Linux 之上以进程之抽象便可运行各类应用而不需关心底层硬件的差别！君不见设计应用之时并不需要考虑 Linux 实现细节就可以使用高级语言和生态构建应用了！云原生底座的责任就是向下纳管各类资源，这些资源包括物理机、虚拟机、甚至于其他 IaaS 云集群节点！

向上提供面向应用的抽象，使得各类应用可以在云端运行，比如 Web 应用、微服务、AI 算法、边缘应用等等，却不需要关心底层资源的差异！所以底座其实是分布式的操作系统。历史已经明了，Docker 容器之类的进程封装技术对于交付有多少的好处，并且是怎么切合云原生理念的（这里不想详细论述 Docker 细节如何，略请君自行脑补一番），那么更加聚焦了，我们将集中讲述基于容器的底座这种技术产品的营造法式！底座可能包括四个部分组成：容器服务、DevOps（其他文章另述）、应用架构治理以及中间件治理。

我们营造这一技术产品的路线是这样的，首先需要找到是否存在某客户有这样的需求，其次会考虑市场的情况，其次会考虑我们平台提供商自己的想法，最后是技术解决方案。为什么会先考虑客户，而不是市场情况呢？因为市场分析大多来自于行业数据报告、竞品分析以及相关的数据分析，是比较宏观的视角，而局部微观视角，比如某个企业的需求也许和这个市场情况的分析略显不同，或者非常不同，或者很难确定是否有很多客户需要这样的产品（决定是不是可以卖或者前期试水）。

如果只从宏观角度去看，有时会营造过于”先进”的产品，一个过于”先进”的产品，可能因为周边生态还不那么”先进”的时候陷入尴尬局面，比如自动驾驶汽车，在社会基础建设没有得到很好的进步时，比如电桩的广泛分布没有得到满足时，用户会十分顾虑续航问题。所以先从某个客户的需求切入，是为了更加接近于实际的情况，但是并不是说不要分析市场情况了，这是平台提供商提供更有竞争力产品的必经之路，否则无法做出比如汽车代替马车的决策了，所以底座平台可以先进一点，不要太过于先进。

以电商为例,如其商业战略是“让天下没有难做的生意”,比如它的业务中台商品中心不得不面对各种类型的业务以及要支撑这种业务下的用户规模，没错！这就是要点，数字化经济特征是从传统的 B 端创新转变为 C 端创新，要求面向用户侧的诸多架构能力，并且是随业务活动而变的能力！商品中心要满足市场需求如下(也有聚焦分析的意思，否则泛泛了):

全场景类目(前台类目和后台类目)
每种类目都有尽可能多的 SKU
每种类目有自己的运营逻辑(微服务应用)
要能够支撑大数据计算以便支撑类目运营
要低成本承接集团所有前台产品应用的中台流量
全地域 99.999% 的可用性、时延 1 ms内
支撑线上升级应用以及无损用户体验.......

【实际情况相当复杂，一般都是不太明确的需求，上面的需求只是例子】

乍看起来这些需求一个基于传统分布式系统就可以满足了，但是这些外部需求里面还藏着一个需求：规模需满足。先说说规模的话题，不知道您曾经了解过这样一个事实没有，目前最大的电商至少有几十万量级的类目，每个类目至少千万级数量的商品 SKU，那么其存储规模是类目数量和商品 SKU 的笛卡尔积，数据量大到无法用常识来理解了，接下来就是基于这个规模的数据查询、分析、操作等逻辑了，如何保证这些动作逻辑不会因为规模原因而出现不稳定性问题？如何保证在规模下的性能？（爆品商品吸引了更众多用户同时查看和挑选），在这样的规模下，如何保证高流量条件下的服务能力？如何在如此规模下完成应用的上线迭代？在如此复杂的业务下团队或者跨团队应该如何组织和管理？如何在此规模下组织运营活动？等等。

另外，对于以上需求，我们要明白点，要分辨其需求来源，上面都是客户的需求，但是实际是来源很复杂，一般而言，来自于客户、内部部门 Leader、老板、竞品分析等等，窃以为要分清楚最重要的、最有价值的部分，而不是都要满足，要敢于拒绝(具体办法，其他文章再论述)，因为需求过于庞杂，只能让产品变得越来越散，越来越没有品位，做产品设计必须做到”有所为有所不为”！

大概您闻出来味道了，并一定会说“看起来这就是找出来要做底座的缘故了！但并不是所有企业都有这个规模，不需要用到那么高大上的平台支撑”，窃以为这种论调估计不乏其人，疑惑简直会铺天盖地踏云而至，本质上底座确实可以支撑超大规模的应用，但是本质上的目标是如何让企业能快速实现数字化创新并稳定地提供线上服务，其实是市场经济与落后生产模式、生产力之间的主要矛盾，超大规模的支撑只是平台化过程中的需求之一，并不代表平台的终极发展方向，否则我们就会单纯进入对技术能力的追逐而没有进一步思考应用多维度支撑的可能性，我们可以这样思考，没有云原生底座之前，大规模业务就运行不起来了吗？但是运作起来是很困难，因为缺乏自动化，成本居高不下，就满足规模需求而言，云原生底座希望的是更低成本更自动化的支撑大规模！所以快速创新以及稳定性的追求是无论大小规模都需要的品性或者说通性，这是市场数字化后的必然。

也许，我们更能问出另一种味道了，上面的需求好像有些理想化，您的判断是对的，首先我想让大家清楚有哪些需求以及内建质量的延伸需求，这样对于书籍这种传播知识的工具而言尚属于比较简洁直接的。但是真实的情况是曲折而反复的：

大部分客户（无论内部还是外部）都很难提出上述需求的，着眼点都在于细节的末节之上或者现场问题，这一点是没有什么可以指摘的，因为企业只关心自己的营收，发倔背后的真正痛点，这就需要平台供应商供给侧来分析和提炼。
需求不可能一次性搞得清楚，除了不断的和客户谈，还要深入他们的业务去体会，但往往是各有各的算盘或者利益，有时也很难进入一个客户的业务，所以要多找同类企业去探索佐证自己的观点是否合乎实际，其他有条件的，还需要和同行多交流，要了解竞品的情况，尤其是最好去看相关的行业报告（权威机构的数据统计报告）。这是一项很需要策略和耐心的活动。
调研的人必须时刻地分析再分析，直到把场景的价值分析出来；场景的价值体现于问题解决的效率、可能市场的占有率以及差异化竞争力。这是个反复再反复的过程，甚至于不仅仅您自己想明白了，还需要让团队、老板和客户都要想明白！

【需求是探索是一项非常困难的而有意义的工作，需要作为重中之重来实施】

那么，至少现在必须说说看到了上面的电商需求后，为什么需要把业务和技术相互隔离的问题了，这也是为什么像底座这种平台出现的原因了，或者说为什么企业需要它。因果关系是，企业更多希望关心的是业务、应用架构问题而不是底层基础设施的问题，而云原生底座平台具备自动化能力、向下纳管各类资源的能力以及向上抽象纳管各类应用的能力，而传统的IT方案按照一种静态的思路构建，对碎片变化的支撑不足，所以企业逐渐都在选择云原生底座作为运行业务的基础，所以云原生底座需要从业务里面剥离出来，透明化的自动化的处理基础设施的问题，给企业带来的价值就是支撑快速的业务创新频率和质量。那么从上面业务需求引申出来的对容器底座的诉求就是：

云原生底座需要支持海量存储，并需要能够根据动态进行自动化拓展和配置。（另外文章进行讨论）。
云原生底座需要支持各类应用的承载，而要求各类应用的承载，就必然同时要求能够打通各类网络。
云原生底座需要能够支撑突发或大的访问流量
云原生底座需要能够支撑业务的连续性和稳定性，任何情况下业务不中断（底层故障、业务上下线等）。其中除了单个集群保证，还需要实现多集群的同地域或者异地多活能力，保证更大范围的业务连续性和稳定性。
云原生底座需要提供高性能的支撑。
业务逻辑需要中间件支撑，涉及透明化集成、资源弹性、自愈能力等，帮助用户轻松构建应用，但是对于应用逻辑的构建无能为力，因为这是业务领域的问题。
还有一个大大的疑问，就是上面只是说明了需求来源，但是没有说在怎样的市场是最有价值的，还有什么样的云原生底座产品是被选择市场最关心的，说直接一些，需要考虑要卖到哪儿里去的问题!估计您会特别奇怪的是为什么要将市场分析放在需求收集和分析之后？那是因为一般而言，只有发现了有价值的微观场景，平台厂商才会思考是不是要做，怎么做的问题，才会继续挖掘其宏观市场价值。但是也不是说非得这种顺序，也可以因为觉得市场有空间，按照市场趋势去寻找实际微观场景的，不过笔者的实践中发现，按照这种看似合理的方式去做的时候，有时候很难找到目标客户，这个问题在实践确实困扰团队很久，其实是自己的选择问题，反过来似乎更容易一些，因为我们事先假定某某市场的空间就是对的，限定了航道，实际情况可能非常不一样，所以导致了很难找到目标客户的问题！找到目标客户是个非常关键的一步，否则我们怎么去验证我们的产品呢？怎么去迭代我们的产品呢？

除了标定我们的目标客户群体以及用户群体在哪里，还就是市场分析里面会不经意透漏出行业的发展趋势，如果要加大成功几率，就必须顺势而为！

从行业情况与市场规模分析来看，对于像我们这样的平台提供商可以决定的赛道是底座支撑型+技术赋能型+集成服务型（容器底座+DevOps+应用架构治理+集成能力等），技术赋能型是属于市场非常青睐的类型，对于集成服务类型，是所有企业隐含的痛点，就是集成交付成本非常高，这是加分项。
因为应用场景的多样，需要支撑 AI、物联网、区块链、边缘计算等等技术能力，这对于平台厂商扩大市场份额有着很重要的意义。
安全能力成为关注的焦点，因为国家战略安全、政策、市场环境导向等原因（比如滴滴事件，将成为企业上云的分水岭事件），如果不构建完整的安全体系，企业上云会受到很大的阻力，所以信创是提升容器底座产品竞争力的途径之一。
大型企业反而对这种技术平台的需求不多，因为他们资金、资源、组织能力以及技术力量相对成熟，所以技术赋能更应该聚焦于中小企业，因为他们还在业务发展期，更不会在 IT 上投入太多精力，更多是拿来主义，而云原生底座平台在自动化运维以及应用稳定性方面相比传统方案有着明显的优势，所以在成本和适用性方面，中小企业非常适合目标企业的范围。当然还需要考虑行业，目前互联网行业相对于其他行业需求的数量和质量都要强，所以可以先聚焦在互联网行业，并可以寻找典型的几个客户进行推进。
用户的核心群体是研发和运维，而在数字化转型或者数字化改革当中，研发人员的话语权越来越重，我们需要给他们提供最贴身的工具。
所有企业几乎都比较担心技术、资源绑定的问题，所以原生运行支持（比如可以原封不动的将整套 Spring Cloud 搬到底座上运行）、开放式平台、标准化交付以及多云纳管成为国内客户非常关心的问题，平台应该充分考虑行业的呼声。
销售方式可以采用：IaaS+PaaS+底座捆绑销售，购买方式采用主流的订阅模式。
在标准的容器底座平台基础上可以考虑行业解决方案。因为这样带着业务进入市场更容易降低企业落地成本，但是对于平台提供商的能力提出更高的要求。
由于国家强制政策问题，信创是必须满足的要求；另外节约能效、碳中和成为新的发展方向。

话题被岔了一下，目前回到业务中台商品中心的需求上来，为了满足这种系统的运营，先要思考的是组织编排（管理）方式！一个是业务侧，另一个是技术侧，技术侧又分成研发和运维等几部分。这里，不太吝啬地指出一个观点：永远不会找到离开组织模型或者社会协作模型的平台系统，如果有人非得要抬杠，说 AI 能让软件全自动化，那么请打住，一个自动化的系统，比如自动驾驶汽车，不也是最终给人服务的吗？根据康威定义的含义，任何技术架构都会反映到组织架构上，反之亦然！而窃以为，最好是先理清楚人的组织问题，对接下来的产品规划很好的指导意义，按照产品领域的叫法，叫做“解决谁是客户、谁是用户并且他们都想要什么的”问题范畴。了解人怎么运作业务十分重要，比如一个非常有感触的例子，网上也好，书籍也好，都说按业务维度去拆分微服务，但是往往落地效果不佳，其实是没有考虑组织方式的典型例子，微服务粒度不重要，重要的是能够以一个小团队自闭环的完成一个服务的设计、开发、发布和运维，不需要过多和其他团队进行沟通，此时代价最小，微服务的快速迭代目标才能实现。有个著名的定律，叫做康威定律，就是说了这种情况。

从组织架构能发现些什么？

研发部门存在协作关系，需要类似 DevOps 平台的能力支撑各种人员角色的协同。（另外文章里讨论）
内外部各类应用面向客户不同可能导致对底座产品诉求是不同的，比如在流量支撑规模、性能、稳定性上的不同，在运维上也因为面向的业务场景不同而存在不同，但是底座产品功能可以做到统一化，所以根本上是能力需求的不同，这是技术领域的问题。
可能存在多种交付形式，由于 Dev 与生产环境软硬件的差异性，也就是运维特性的差异性，另外研发和交付团队是两个团队，交付设计传递过程中产生信息变形或者理解差异非常正常，这些都导致交付成本居高不下，虽然这个完全靠技术不能得到 100% 的解决，但是在技术上需要往低成本的交付自动化能力而努力。
部门或者组织之间可能存在数据安全的问题，需要得到重视。（另外一篇文章详细讨论）
在公司级别，可能存在需要全局技术能力治理的需要，比如将 IT 统一分配的管理的需要，背后的动因是节约 IT 投入成本。
APP 前后台账号体系的需求，也同时存在需要对接各种账号体系或者服务的需求。IAM 是底座平台对账号体系的支撑子系统。（IAM 可以归类为业务层支撑，IAM 在另外的文章里讨论）
由于这些组织部门不是在业务系统构建时才有的，它一定存在很久时间，所以传统的系统遗留或者核心 ERP 系统的存在，在不可能为已经存在的系统再做一遍云原生改造的情况下，一定会产生系统集成的需求。另外隐含着即已存在的微服务系统透明化上云的需求，以便在最低成本下，获得容器底座的能力，以便加强业务应用的技术支撑能力。
企业间可能存在集成关系以便构成企业间协同关系，所以开放平台等连接生态的机制需要考虑。
无论基础设施也好或者业务应用也好，都需要运维部的运维保证，所以需要能够给予云原生的思维，构建自动化的甚至于智能化的运维工具体系提供给用户使用。
无论是跨部门还是跨公司组织交付，都需要共享的镜像服务作为支撑。

上图可以看到的是，客户是诸如 X 划算这样的上层业务组织，用户们则是如上图一般其具体业务运营的人群所构成，而底层技术设施用户协同之实现受到业务层需求的牵动或者影响，这可能因为领域知识的不同以及团队归属的不同而带来实操时无法获得一致的效果等现象，更深入一些的话，不同团队归属还隐含一个交付的大问题，分属于不同团队的研发环境与生产环境软硬件等条件不一致，导致交付成本高的问题，所以对于底层基础设施的实操要从业务应用角度抽象简化和自动化运维事项，以便从高纬度视角统一意图的效果变现。

可以看到的是，分析组织形式不仅仅是协作分析，还会引申出很多技术上的诉求。从业务需求、市场分析以及组织分析所归纳出来的第一阶产品架构是：

窃以为这是第一阶的产品架构，为了使得更高效和更低成本，需要结合引申的技术需求来做此类技术产品架构的调整，理由是没有办法从技术实现的规划是在浪费时间，收敛后形成一个结合的第二阶产品架构. 产品架构最终是给实现商业目标一部分而产生的产品蓝图（说其是一部分，是因为商业蓝图不可能只依靠技术来实现，它是一个集业务能力、生态、组织、战略、商务、技术等等为一体的事物)。

不仅仅是对技术单纯的分析，同时也涉及平台提供商的能力是否可以落地实现的判断来取舍一部分，当然对于底座平台核心的并不可或缺的要素则不能被舍去，但是可以根据一定考虑简化和合并。（简化不等于削弱，反而是强化的一种有效途径）此时也只是纯技术因素借入的前奏（前面的分析中，其实时时刻刻都在考虑技术上的事情了，只是没有那么深入底层细节，更多聚焦在价值上），因为我们营造的是技术产品而不是单纯的业务产品，所以不考虑具体的技术因素是行不通的。

标准化网格基础设施：将注册发现、服务网关、API-M、服务网格、观察性以及内件质量（中间件 Mesh 化）都可以用统一的基础设施管理起来，形成标准化的、简便的应用架构治理设施。

过去笔者曾经领导过几个产品团队，发现一个十分有趣的现象，这个现象和人们的认知有关系，团队几乎大比例的产品经理都不懂技术，甚至狂到吼道“我一个产品经理为什么要懂技术啊”，我们是设计一套技术产品，不懂技术如何才能懂得这个市场？不懂技术如何才能评估产品设计对不对？不懂技术如何和技术团队沟通落地？这就如卖茶的却不会喝茶，如何向客户推介茶呢？以上完全是认知问题导致的！作为技术产品的规划人员，首先是一个合格的技术研发人员才行，这里只是给平台提供商提个醒，招人要有标尺。

接下来进入第三阶产品架构的设计，也许认为进入第二阶就好了，但这样的规划不完整，理由是市场不是单方的，客户需求是要全部满足的，但是并不等于供给侧不需要创新，否则市场上的云原生底座都长成一个样子，还有什么市场可言？供需关系才是市场本质，客户原要的马车，厂商给提供了一个成本更低并且可以不用休息的汽车，这个例子是供需关系的体现。

厂商增加了原生运行模式能力，也就是不需要改动或者少改动业务代码就可以快速上云，这是所有企业隐含的痛点！
厂商增加了服务自治自驾驶能力：服务治理参数配置对于业务人员而言是比较困难的，传统方式依靠运维团队支撑，但是两个团队的协同成本就会提高，很不 DevOps！所以服务治理需要自动化，自动根据负载流量条件参数。进一步减少客户运维成本！
厂商增加了标准化 ISV 交付能力，通过通用型、开放型的交付机制，比如 OAM，将交付能力标准化，任何环境都可以交付，和厂商平台特征无关，并进一步将组件和运维特性隔离，适应各类差异性环境。
客户普遍隐含着不希望绑定到特定技术栈的考虑，防止厂商绑定、防止技术绑定等的后期成本。云中立(多云)成为一个亮点竞争力。
......

以上增加的竞争力是例子，您可以根据自己的实际创新，而创新不是无源之水，都是从客户价值出发的，以上的创新都是行业隐含的痛点，但是有时从客户场景出发确实也很难评估出来，需要发挥我们的主观能动性。

也许读了上面规划的过程，会有人跳出来按着我的头在地上摩擦的嚷起来:”太复杂了，我直接给个设计结论不就可以了嘛？”,并不武断的讲，这样一步到位的作为普遍存在，我只能说这些人根本不懂市场的复杂性以及人性的复杂性，过于相信思维的力量（如果是搞自然科学，则完全可能没有问题，从笔尖发现一个新的星球或者理论完全可能），有时把竞争力错判或者放错了地方，这也是往往厂商和客户认知曲线不同的原因，厂商那边也许只需要一些看起来很 Low 的方案就可以了，但是行业呢？

厂商只是解决客户的问题呢？还是需要考虑解决行业的问题呢？况且只针对某些客户的话，随着规模的扩大，厂商必须分兵来对应，因为每个企业有不同的诉求，能够支撑多大规模？如果不是在不断在各个行业深入调研的基础上并试图设计一个普惠的、普适的并和具体业务解耦合的技术平台，这样的技术平台还能复制到各个行业吗？

所以需要清醒一些，通用化需求和定制化需求会长期存在，也必然不会出现单个存在的情况，所以 K8S 这种技术平台，采取抽象框架，提供通用能力，同时也可以通过 CRD 拓展出各种针对不同需求的能力来，这是一种在技术上的优秀解法，当然厂商需要自己的平台价值主张落地，还需要考虑更多，比如商业集成等问题等等。

从第三阶产品架构图来看终于我们有了一个认为相对完整的产品规划了，那么我们继续进入技术架构的设计思路讨论，同时必须认识到产品营造是个不断循环前进的过程，并不意味着进入技术架构设计阶段后产品规划不会稍微改变或者被优化。

从上面电商场景出发，逐步规划了底层云原生底座的产品蓝图，但读者是不是觉得不具备普遍性能力？您的感觉是没错的，事出反常必有妖！我们可以在更多行业和场景去探索，但是会发现核心的通用需求都差不多，更多是一些上层业务需求的差异，但是如果一个一个来分析，那么此文肯定也写不完了，姑且以上面的电商实例来推演。

后面第二篇有关底座的文章是从底座产品规划蓝图来分解和设计技术架构。