不要仅局限于技术实现细节

星球群里，有同学问了这样一个问题：docker的性能是不是没有本地服务好？问题的背景大概是技术负责人向CTO汇报的PPT如此写道：考虑到性能问题，当前微服务架构暂时不采用docker部署管理。

docker的性能真的不好吗？微服务架构下适不适合采用docker部署和管理应用节点？要回答这个问题，要放在具体的条件和语境下来分析，特别是在影响整个技术团队研发效率和质量的技术选型决策时，更应该慎重。

技术选型这件事，没有谁比谁更好，只有合不合适。且这句话有一个前提，那就是技术选型决策时，要考虑到团队甚至公司当前的具体情况，比如：

• 业务复杂度：如果是较为简单的业务逻辑，且用户量不大，单体应用性价比最高。
• 企业发展阶段：创业阶段小公司+低流量，做微服务拆分+容器化管理应用，完全没必要。
• 技术团队规模：二三十人的小技术团队，微服务+容器化的成本会居高不下，且业务迭代速度可能受影响。
• 基础设施建设：容器化虽然具有很多优势，但需要很好的基础技术设施+完善的流程+富有经验的工程师来支撑落地。

类似的对比因素还有很多，因此技术选型并不是哪个热门用哪个，大厂用哪个就学哪个，哪个看起来更好就用哪个。而更应该考虑到具体情况来做具体分析，进而做技术选型决策。

质量保障工作的开展也是如此，根据具体需求分析测试点，然后设计测试方案和测试用例，采用不同的测试方法来保障最终的交付质量满足业务需要，而不是一切对标大厂。

近几年从大厂传出来的如AI测试、低代码开发、流量录制回放、生产全链路压测、混沌工程等都是很热门的质量和稳定性保障技术实践。

这些技术实践看起来很高大上，但它真的不一定适合当前阶段你所在的团队，且引入的成本和难度往往超过你的想象。

 

当然，微服务架构+容器化的优势还是很明显的，比如更便于快速开发以支撑业务的快速迭代、快速灵活的部署方式、更强的弹性扩缩容能力。但有优势就必然存在不足，比如：

• 运维和管理成本增加：微服务需要构建/测试/部署/运行几十上百个独立服务，支持多语言和多环境。
• 分布式系统的复杂性：微服务架构的复杂性带来了若干新的技术挑战，比如网络延迟、容错性要求变高、序列化反序列化、数据一致性等各种问题，这些其实是隐形的技术成本。
• 调用链路和可测性问题：多个应用和技术组件之间复杂的调用关系会让测试工作的难度几何倍数提升，且服务的部署和发布需要更强的组织协调能力。

而容器化现在最成熟和应用最广的K8S技术栈，也存在很大的决策挑战，那就是学习曲线比较陡峭，管理成本也不低。

 

微服务架构和容器化本身并不是银弹，依然只适合某个阶段的特定类型企业，也只能解决特定范围的问题。

如果全部自建机房和彻底容器化，那资源成本和日常维护管理成本将居高不下，大部分公司没这么多的技术投入预算。

如果全部上云，其实成本也不低，而且上云之后服务的稳定性基本就交给了云厂商。

前几天阿里云服务宕机的影响还历历在目，近几年很多公司也开始下云或者做混合云的服务部署和管理，这背后的逻辑也是在不同阶段根据情况的技术决策。

比较符合逻辑的技术和业务演进逻辑是这样的：初创企业和小公司，通过单体应用快速搭建和上线提供服务；

上了一定规模，业务复杂+流量起来，开始进行分布式集群部署，进而采用微服务架构，随之而来的则是分库分表、消息队列隔离等一系列的技术改进。

当业务规模进一步扩大且流量更高时，技术需要支撑业务快速迭代和大规模部署，这个时候考虑到长期的降低成本，容器化优势才开始逐渐显现。

而且在实际的工作实践中，为了降本增效，容器化往往会超预算提供服务(即资源超卖)，在流量高峰期会出现一些不可描述的问题。当然，这也是服务资源削峰填谷的一种方式，有优有劣。

关于微服务架构和容器化更详细的介绍，可以看这篇文章：https://zhuanlan.zhihu.com/p/43357441

 

很多时候我们遇到技术问题，很明显的一个误区就是陷入技术实现细节里不可自拔，正如文章开头提到的案例一样，太陷入细节，反而会忽视整体的思考。

对技术的学习和理解，不能回避整体设计，因为更好的整体设计才能为团队提供更高的研发能力支撑。

在进行技术选型和决策时，除了考虑技术本身的优劣势，还更应该考虑到团队当前面临的挑战和所处阶段，技术成本预算以及技术和业务之间的价值关系。

不断思考问题的本质，以构建卓越的软件工程为目标，从更高维度去寻找更大范围更合适的解。