群里,有同学问了这样一个问题:docker的性能是不是没有本地服务好?问题的背景大概是技术负责人向CTO汇报的PPT如此写道:考虑到性能问题,当前微服务架构暂时不采用docker部署管理。
docker的性能真的不好吗?微服务架构下适不适合采用docker部署和管理应用节点?要回答这个问题,要放在具体的条件和语境下来分析,特别是在影响整个技术团队研发效率和质量的技术选型决策时,更应该慎重。
类似的对比因素还有很多,因此技术选型并不是哪个热门用哪个,大厂用哪个就学哪个,哪个看起来更好就用哪个。而更应该考虑到具体情况来做具体分析,进而做技术选型决策。
质量保障工作的开展也是如此,根据具体需求分析测试点,然后设计测试方案和测试用例,采用不同的测试方法来保障最终的交付质量满足业务需要,而不是一切对标大厂。
近几年从大厂传出来的如AI测试、低代码开发、流量录制回放、生产全链路压测、混沌工程等都是很热门的质量和稳定性保障技术实践。这些技术实践看起来很高大上,但它真的不一定适合当前阶段你所在的团队,且引入的成本和难度往往超过你的想象。
微服务架构和容器化本身并不是银弹,依然只适合某个阶段的特定类型企业,也只能解决特定范围的问题。如果全部自建机房和彻底容器化,那资源成本和日常维护管理成本将居高不下,大部分公司没这么多的技术投入预算。
如果全部上云,其实成本也不低,而且上云之后服务的稳定性基本就交给了云厂商。前几天阿里云服务宕机的影响还历历在目,近几年很多公司也开始下云或者做混合云的服务部署和管理,这背后的逻辑也是在不同阶段根据情况的技术决策。
比较符合逻辑的技术和业务演进逻辑是这样的:初创企业和小公司,通过单体应用快速搭建和上线提供服务;上了一定规模,业务复杂+流量起来,开始进行分布式集群部署,进而采用微服务架构,随之而来的则是分库分表、消息队列隔离等一系列的技术改进。当业务规模进一步扩大且流量更高时,技术需要支撑业务快速迭代和大规模部署,这个时候考虑到长期的降低成本,容器化优势才开始逐渐显现。
而且在实际的工作实践中,为了降本增效,容器化往往会超预算提供服务(即资源超卖),在流量高峰期会出现一些不可描述的问题。当然,这也是服务资源削峰填谷的一种方式,有优有劣。