容器化和Service Mesh实践

昨天有幸去中科院计算所参加了“CCFTF第11期”容器化和Service Mesh实践技术会议，分享嘉宾和到场听众都是北京一线互联网公司的技术大拿们，做基础架构的同学居多。

第一位分享嘉宾是来自华为的架构师田晓亮，晓亮是负伤上阵，拄着拐杖演讲，让人感动。分享的主题是华为公有云的微服务实践。晓亮首先介绍了华为云微服务解决方案，提到了他们的go语言开发框架和对spring cloud的兼容。接着，跟大家普及了service mesh的概念（一种基础设施，服务通过service mesh通信；轻量的网络代理；可靠的复杂网络拓扑传输，将服务变为云原生服务）和好处（解放开发者，改造遗留应用为云原生应用，0代码侵入，学习曲线低）。然后，重点介绍了华为自研的商业级service mesh方案mesher（用go开发的），介绍设计理念（如侵入式非侵入式结合，不绑定基础设施等）和整体架构，并分别就数据面，控制面，注册发现，路由管理等进行了展开，分析了service mesh代理带来的性能损耗（请求多了用户态-内核态的调用）。最后还介绍了两个应用案例，以及一些最佳实践（比如，用sidecar方式部署而不是host方式）。

华为Mesher架构

第二位分享者是百度外卖的李大帅，主题是百度外卖容器化改造之路。大帅开玩笑说自己从来没有跳过槽，但是已经换了三家公司。大帅首先介绍了外卖私有云的背景：为了达到分时复用、智能运维、按需分配、弹性计算等目标，再加上框架统一（WODP、brpc等），完整中间件（WFE、BNS、huskar等）等优势。然后，大帅介绍了上云包含的内容和整体架构，并对每个模块进行了详细介绍，比如网络方案选型Flannel，k8s调度模块，服务注册Huskar，日志系统EFK，基于open-falcon的监控方案，镜像仓库系统Harbor/Ceph，基于阿里开源P2P传输技术的快速分发系统。特别地，重点介绍了他们自研的自动扩缩容模块，分为策略层/聚合层/决策层，非常技术范儿。

百度外卖云整体架构

第三个topic来自滴滴的谭霖和李炳毅，谭霖介绍了滴滴弹性云实践创新，炳毅分享了滴滴service mesh的演进思路。谭霖老师首先介绍了弹性云的业务接入情况（20000容器数）和整体架构，以及美东独立部署的事情。然后，提到了云化的四个阶段（虚拟机，富容器，cloud native，serverless），滴滴目前还处在富容器阶段，考虑到用户自由度和运维效率经验曲线，未来滴滴可能较长时间还会处于这个阶段。滴滴弹性云目前主要聚焦解决使用体验和快速扩缩容，谭老师介绍了主要产品功能，并讲解了流量无损发布、监控、日志、持久化存储等方案，最后还分享了踩过的坑（如etcd用V3，探针区分部署和运行等）。炳毅则主要分享了他对service mesh的一些感悟和实践体会。首先分享了Inrouter中心式代理和侵入式SDK的思路，sidecar类似于proxy，要热升级，连接迁移，运维友好 ，动态配置，超时管理等。然后介绍了为什么滴滴要用service mesh（服务编排，多样治理，业务多样，业务繁多等问题无法高效解决，service mesh是可能落地的方案，且有大公司背书等）。接着，介绍了滴滴采用service mesh的三阶段（中心式proxy，中心式proxy+侵入lib，中心式proxy+侵入lib+service mesh），以及实践中的一些重点（数据面：研发效率>可运维性>稳定性>性能>技术储备；控制面：开放能力+融合已有生态）。最后，炳毅还就四个方面的问题（业务共建，拥抱开源，生态融合，云上落地）给出了他的思考。

滴滴流量无损发布方案 炳毅给出的servcie mesh实践中的关键技术问题

第四个主题是新浪微博混合云产品负责人朱晓巍给出的“微博混合云平台的产品化探索”。晓巍首先跟大家介绍了微博云弹性调度的三个阶段，从手工，到定时，到智能调度，并分享其中的一些心得，比如用慢速比做指标。然后，晓巍重点从产品的角度介绍了他们是怎么思考云化整件事的，从流程化、自动化、可视化和移动化等四个方面介绍他们项目的实施细节。接着，晓巍跟大家普及了产品思维（找到痛点，化繁为简，快速迭代，协作沟通），并跟大家展示了他们的新产品思路（区块链做资源共享）以及二维码小程序做运维的崭新用户体验。

微博云产品结构

最后分享的是来自今日头条的黄龙。黄龙兄则从头条在微服务实践中的问题（隔离性：资源分配，端口隔离；轻量级：混合部署，快速扩容）入手，介绍了他们的容器化之路。首先，黄龙介绍了头条的技术选型（编排k8s，service 模型，网络模式，平台构建），以及平台构建的容器化方案的总体架构。接着，龙哥从实际问题出发，分别就CPU隔离（多语言高并发），网络架构演进（bridge->host->auto host）等主题介绍了他们的解决方案。然后介绍了一个案例引出他们现在的挑战，头条存在15k实例的服务，更新部署效率低，服务发现组件负载太高会挂掉，稳定性很差，因此在服务发现组件前方构建了naming组件。并由此展开了服务治理优化的讨论，引出头条实践service mesh关注的问题，以及尝试的架构。

头条service mesh尝试架构

最后，还有一个panel环节。大家一致认同今年是service mesh元年。各位嘉宾讨论了service mesh的技术栈，如何落地service mesh（找到适合的业务场景，从问题出发），以及要解决的问题（性能问题，就近调用，服务发现，稳定性等）。感谢组织方的精心准备，感谢嘉宾们的精彩分享！

panel环节，各位大佬齐亮相