一、谈谈云原生
首先介绍下比心陪练，比心APP是线上电竞游戏陪练领域的开创者和领军者，致力于让年轻一代“玩出梦想”，以游戏竞技为核心，打造全球第一的技能分享平台。成立至今六年多以来，比心APP已积累超过5000万用户和超过600万电竞游戏陪练师。
随着公司业务的高速增长，运维团队也开始着手容器化方案的落地， 经过两年的奋战，比心整体完成了业务应用容器化，目前生产环境运行容器数量5000+，由两套集群组成，大大提升了运维团队的管理效率。
谈起容器化，不得不说下现在业内最火的课题“云原生”，在传统的IT领域里，开发周期长、研发效率低下、资源不能够得到有效利用，而云原生技术利用分布式技术、弹性、可扩展和灵活性等特点给现在IT技术带来一场划时代的变革。那么云原生到底是什么，CNCF 1.0中这么定义的，云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
说到这里，其实一千个人心中就有一千个“哈姆雷特”，每个人对云原生的理解都不一样，云原生，顾名思义，是面向“云”而设计的应用，天生就适合长在云上，运行在云上，它为实践者提供了一条低心智负担的、能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径，是一系列最佳实践的结合。
经常也有人问我，如何去理解云原生、容器化这些技术。我更觉得它是一个标准化、一个行业的标准化，
它是整个基础设施的“Linux”，屏蔽了底层的异构硬件，异构系统，异构环境，对上提供一整套运行环境
整个IT架构的绝对标准，让迁移，让各公司乃至合作伙伴技术衔接更方便
开发、测试、上线、运维、监控和升级等环节中形成新的技术标准。由这个云原生作为企业基础架构的“底座”，让业务开发迭代周期更短、更高效，让基础设施更弹性，让成本更低，让按需付费成为可能。
二、技术选型之路
kubernetes篇
说了那么多云原生，是为了让大家更好的去理解这个新的架构，新的指导思想。上面也提到云原生的代表技术，那这里就不得不谈下微服务和容器技术，比心的微服务技术落地还是比较早的，早在成立之初就开始使用了spring cloud架构体系，后来在18年的时候全面转向了dubbo，至于为什么转，这里就不详解了，毕竟spring cloud 和dubbo各有优劣，软件架构没有什么银弹，只有适不适合。
大家都知道，微服务的落地，必然会带来架构和运维的复杂度，毕竟服务多了，需要的服务器数量也多了，发版迭代的次数也增加很多，因此对于运维的挑战随之而来。我们能否快速上线，能否快速扩缩容，能否用最少的人力管理庞大的基础设施，这些都是运维团队需要面临的问题。而kubernetes天生都具有这些能力，不需要团队投入太多的研发能力就能赋予。至于为什么kubernetes会成为这个行业的标准，这里我就不介绍了，这样的文章很多，大家可以自行搜索下。毫不犹豫，比心的运维团队在2018年12月份，也做了一个决心，那就是落地kubernetes，让比心的应用都运行在kubernetes平台上，这一点也得力于运维团队领导以及各位技术老大的支持和认可。
既然我们想做kubernetes、想使用云原生的架构，那我们就开始梳理各项准备工作，第一步，我们就做了阿里云标准化工作，那就是迁移vpc网络，由于早期公司用的是阿里云的经典网络，导致网络隔离性不是很好，网络规划混乱。这个事情整个技术团队历时三个月完成，让整个阿里云的资源管理更规范，比如服务器计算机名的规范，配置的规范，网络的规范，安全组使用的规范等等。当然，整个迁移对技术的挑战也是有的，比如kafka、zookeeper、es这种有状态集群的迁移，并且在迁移的过程中的零停机的，光kafka的迁移，我们就演练了不止20遍，各个细节、环境都仔细把控，功夫不负有心人，最终是成功、顺利的完成了这次迁移。
2019年2月份，我们就开始了kubernetes的建设、验证、性能测试等，第一期的计划是完成整个测试环境的落地。在技术选型上，我们也是纠结了很久的，毕竟运行在公有云上，阿里云也出了相关的kubernetes产品，ACK，并且还是免费的，只产生ECS费用，跟自建成本差不多。最终再三考量，加上对ACK产品的稳定性还持有怀疑态度，我们选择了自建，第一套kubernetes的版本是1.11，当时是直接使用原生的二进制一个组件一个组件部署的。这种部署方式熟悉kubernetes的都清楚，所有的自动化工作都需要自己团队来做，后期的升级、备份都要做很多准备工作。
关于网络选型这块，在公有云上没有太多的选择，比如说用不了calico，因为无法跑bgp。最终我们选择了flannel，也做了相关的网络压测，满足我们的业务场景。并且针对flannel所用的技术原理，本身团队也比较熟悉。
镜像仓库篇
镜像仓库我们用的是vmware开源的harbor，harbor目前也托管在cncf，是一款比较成熟的镜像管理工具。当时我们用的是harbor 1.6版本，功能比较简单，没有自动化清理镜像功能，然后我用go语言开发了一个简单的小程序，可以指定某个project下的镜像保留最近5次版本。后来随着harbor的迭代，镜像生命周期的管理，垃圾清理功能也都有了。到目前为止，使用上还算稳定。并且我们还对接了域控，使用ldap来管理权限也很方便。
在高可用方面，harbor可以做仓库之间镜像复制，存储可以选择分布式存储、共享存储等，在阿里云上，我们这边没有做太多复杂建设，直接使用阿里云的云盘，本身就有三副本技术，另外生产环境做了两套harbor做镜像同步，起到热备的作用。
监控篇
毫无疑问，我们也是采用了业内通用的监控平台prometheus，原生的prometheus不能满足我们的业务需求，并且本身它在高 用这块没有什么好的方案，这一块我们做了很多二次开发的工作。做到了服务自发现、自动监控。我们的第一代监控主体的技术栈采用了consul做注册中心，prometheus做监控，grafana做展示。 目前我们已经研发了第二代监控平台，接入thanos，做数据整合、统一查询，并自研了自己的监控中心
整个监控平台的架构如下：
日志篇
这个使用的架构也算是大家耳熟能详的技术栈ELK，通过filebeat搜集到kafka，然后用logstash消费、过滤发送到es集群，最后使用kibana进行查询。针对日志这块最大的挑战不在于如果打通这个流程，而在如何处理大量的日志，尤其当日志量每天几十TB的时候。我们针logstash、es做了大量的优化工作。我们还自研了cicd，k8s多集群管理平台，这个作为专项后续一一分享。
三、原生的kubernetes远远不够
kubernetes高可用
kubernetes是一个很好的开始，但不是终点，它提供了一个很好的基础设施底座，具备强大的可扩展功能以及声明式API。既然是底座，那么针对高可用方面就有很严苛的要求。如果发生集群方面的故障，带来的损失可能就会被放大，以前使用虚拟机可能只是影响单个服务，而使用k8s就可能会影响一片服务，甚至整个业务。鉴于此，虽然kubernetes本身master节点就具备高可用的能力，我们仍然采用双集群的模式去承载应用。如果一个集群出现问题，可以快速将流量切换到另外一个集群。
HPA太局限
在我们使用动态扩缩容的过程中，还是踩了一些坑的，比如发版的过程中应用莫名的扩容了、我们手动扩容了某个服务又莫名的缩容了，另外社区支持的指标类型太少，基本都围绕着内存和CPU指标，无法满足日益复杂的业务场景。因此我们做了很多自定义的开发，支持了多种指标，后续还会对接各种业务场景，目前已经实现的参考下图：
deployment不够灵活
在业务发展早期，基本deployment也能满足业务需求，随着使用越来越多，发现这种controller针对一些特殊的业务场景，还是有些问题。比如，在发版的过程中，有时候为了验证应用的可用性，需要先发一个pod进行灰度验证，那我们只能使用多个deployment去解决。再比如，发版的过程中，如果ip地址不变可能对使用者更有友好。这个时候，kubernetes crd的强大之处就体系了，用户可以根据自己的需求去定制controller。云原生团队在调研、实践功能更丰富的workload，后期计划支持原地升级、发版的时候ip地址不变、简单灰度发版等
kubernetes scheduler还是不够
大家都知道，很多服务上kubernetes的原因之一，就是因为可以有灵活的调度，可以节约资源。当我们资源比较紧张的时候，现有的scheduler就无法满足我们的需求了。比如某台节点的CPU压力很高，上面运行了多个高负载的容器。但是kubernetes scheduler调度的时候只是根据request值来决定调度哪台node，并没有参考节点的压力，把高负载的容器给打散。这块我们也在自研调度引擎，在社区本身功能的基础上，增加自动识别负载比较高的应用，做打散操作。
四、总结
经过两年的努力，除了一些有状态的应用，目前test、uat已经全面容器化， prod环境容器化率也已经有95%以上，k8s平台承载的docker数量有6000+，目前效能工程团队还在实践flink、spark等大数据的平台的容器化，相信未来不久，我们能做到所有服务弹性、按量使用。
经常会有人问我们，我们做云原生、做kubernetes的意义何在。我们的愿景是：
让kubernetes成为基础设施最坚实的底座
让使用kubernetes的人感受不到它的复杂，一切可视化
用云原生加速企业发展、提效降本
我们更希望它真实的为比心、为业务带来实实在在的价值
以上这些更多的是为了给大家展示比心的容器化大致历程，上面的每个技术点，后续效能工程团队都会用专项的形式向大家输出。这是我们的给大家输出的第一篇文章，后续还会更多。如果您对云原生，对kubernetes，对容器化技术感兴趣，欢迎和我们一起探讨，共同进步、共同成长。
