“一花一世界，一叶一菩提”，微服务的世界里，业务千变万化，管理纷繁复杂，不是我们凡夫俗子可以掌控，需要有一个“肚里能撑船”的大佛来统一管理，他就是“容器”。
容器技术的引入本质上是需要解决微服务改造后，服务尺寸缩减、服务数量激增、软硬件环境依赖差距增大等等实际部署问题。同时，在互联网企业采用DevOps概念后，我们软件工程师和架构师，变得需要开发运维两手抓，系统和运维管理经验的短板逐步暴露出来，大量的宝贵时间被花费在了准备环境（开发、测试、准生产、生产）、调整发布管道、监控和故障响应中。
一个问题越来越突出：到底有没有一个方案可以把系统后台的应用部署、业务高可用、资源弹性伸缩、发布自动化、运维自动化都统一管理起来，让我们可以安心地设计、开发、测试应用软件的核心价值模块呢？
作为架构师，一大主要角色就是技术的选型与决策，我们分别从两大容器技术和两大容器编排方案中，寻找符合我们个人品味的Fashion吧。
说到容器第一印象应该就是Docker。那我们就从Docker开始感知起来。
之所以Docker这么火，正式因为它体现了容器的本质：微小、敏捷、通用。它拥有简单易用的命令行工具、静态镜像和动态容器实例的清晰界定、高效的资源隔离和限制、完整的状态机模型、灵活的网络技术选型、和强大的生态圈系统，无可争议地成为了容器届的一哥。
光有容器技术显然是不够的，要让容器可以充分的运转起来，我们还需要一套编排系统或者一个全自动的PaaS平台。Cloud Foundry就是一个继承了RunC容器技术和便捷PaaS概念的体系架构，它可谓是Docker技术的一大竞争对手。如果我们以外卖服务作类比的话，Docker容器就是快递送来的速冻水饺，我们还需要用电磁炉或微波炉做最后的加热处理，完成容器镜像里应用代码的运行时、依赖库、运行服务等元素的配置和准备；而Cloud Foundry就是外卖小哥送来的熟水饺、香喷喷热腾腾，开包即可食用，用户只要发布代码和简单配置，所有的依赖关系在容器平台实现了自动匹配和准备。
如果说Docker容器是金庸笔下的《笑傲江湖》的令狐冲的话，那么现在它最愁的问题就是该选择华山派的气宗还是剑宗作为自己的发展方向呢？
在容器编排里也有两大发展思路：一个是Mesos推崇的气宗，先花费10年（Mesos平台）打牢气功底子，让数据中心的所有资源尽在掌握；然后以气运剑，不管是“苍松迎客”还是“白虹贯日”都可以得心应手，我们既可以在上面跑Marathon长业务，也可以跑Chronos作业调度，还可以运行Spark Steaming大数据流处理。
在Mesos、Marathon之上，又整合出了一个更加酷炫的概念，DCOS - Data Center Operating System（数据中心操作系统），把整个数据中心当成一个操作系统来管理，很有用华山气宗一统武林的决心。
容器编排的另一个集大成者就是Kubernetes，它走的是华山派的剑宗路径。不拘泥于武功的路数和招式，应对方的剑招而生，“独孤九剑”以不变应万变，克尽天下武功。不管你是要起Web服务，还是后台数据业务，Kubernetes通过其强大的九招剑法，败尽天下英杰：1）Pod：破容器之关联； 2）Controller：破应用模式之复杂；3）Label：破资源之限制；4）Probe：破故障之频发；5）Service：破负载之不均；6）PVC：破存储之难管；7）ConfigMap+Secret：破配置之混乱；8）RBAC：破安全之风险；9）Helm：破应用发布之艰难
最后，学了这么多武功，不如就让我们将之组合起来，实现容器应用的弹性扩缩容，支撑起电商网站的秒杀抢购平台吧。
国内外一线大厂技术大咖与慕课网组成专家团队12个月磨一剑
千万级电商项目从0到1到100全过程
涵盖Java程序员不同成长阶段的问题及最佳解决方案
随时随地看视频
热门评论
-
仄言丶2019-11-08 0
查看全部评论实现时 是按照上面的架构图实现吗