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

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

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

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

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

 

• 厂商增加了原生运行模式能力，也就是不需要改动或者少改动业务代码就可以快速上云，这是所有企业隐含的痛点！

• 厂商增加了服务自治自驾驶能力：服务治理参数配置对于业务人员而言是比较困难的，传统方式依靠运维团队支撑，但是两个团队的协同成本就会提高，很不 DevOps！所以服务治理需要自动化，自动根据负载流量条件参数。进一步减少客户运维成本！

• 厂商增加了标准化 ISV 交付能力，通过通用型、开放型的交付机制，比如 OAM，将交付能力标准化，任何环境都可以交付，和厂商平台特征无关，并进一步将组件和运维特性隔离，适应各类差异性环境。

• 客户普遍隐含着不希望绑定到特定技术栈的考虑，防止厂商绑定、防止技术绑定等的后期成本。云中立(多云)成为一个亮点竞争力。

• ......
  

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

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

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

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

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

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

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

架构图可能在第二篇文章中有所变化，目前只是预告一二：

1) 多云体系架构以及解决方案 

2) K8S 技术优化方案 

3)  自动化控制器方案 

4）标准化网格 

5）标准化交付.......