【51CTO.com原创稿件】2018年5月18-19日，由51CTO主办的全球软件与运维技术峰会在北京召开。来自全球企业的技术精英汇聚北京，畅谈软件技术前沿，共同探索运维技术的新边界。而在本次大会上，除了众星云集的主论坛环节，12场分论坛更是各具特色，在19日下午的“微服务架构设计”分论坛上，来自饿了么计算力交付部资深工程师李健先生发表了精彩演讲。
作为饿了么企业内部多个基于容器的云计算项目的开发负责人，李健拥有多年丰富的容器系统建设经验，推进了饿了么平台容器化进程。尤其擅长将容器的敏捷性和标准化进行企业级落地。为应对万物互联时代持续计算带来的机遇与挑战，李健致力于打造更加便捷的计算力服务，促进高性能计算、大数据和云计算等多元计算模式的深入融合。
饿了么计算力交付部资深工程师李健演讲
李健此次的演讲主题是“eleme容器平台”，这个平台是基于容器的一个管理系统，谈及管理系统，李健认为，虽然现在公有云比较多，但大家都要面临的一个场景就是混合云。他的演讲主要分为四个部分，即计算力交付、技术选型、算力外卖和基于kubernetes的拓展方案。他坦言，最初在业务快速增长的过程中，资源规模增长非常迅速，导致我们服务器的类型特别多，管理的任务也很重。因为要适应业务，交付的需求也多种多样。
一、计算力交付
李健认为，计算力交付作为一个抽象的概念，实际上是我们把物理资源抽象出来的一种输出，是对于开发人员的一种输出。饿了么的物理资源，讯息资源量很大，人力有限，我们不可能无限的去扩张，于是我们就想实现一种方式，将它标准化，这样可以极大的减少成本，也可以更轻松的去管理更多机器。基于以上，我们计算交付部门出现了。我们认为一切的交付行为都是应用，所以饿了么面临的关键变成了怎么样去交付这个应用，怎么去管理这个应用。
说到这里，就不得不提容器技术。容器技术很早就出现了，Docker为容器做了很大的贡献，它真正面向了应用，可以移植，可以跨平台的特性，特别是它打包方式，使得所有的服务，都变成一种统一的打包方式。这就是应用的一个标准，在这种标准之上，我们可以把这个应用跑在我们想跑的任何一个平台上。只有这样的话，我们才有可能进一步的去做到，不论是自动化运维，还是AIOPS或者是大数据等等，这些更加的降低人力成本，提高资源使用率的目标。
具体看来，我们会交付三个事情，首先是用户数，就是你把应用交给我，我来帮你部署，让服务跑起来。其次是标准服务的一键交付，比如大数据需要一套环境，或者某某部门他需要一套环境，一套环境里面他包含了ABC很多服务，这些服务和其他服务有隔离性，服务之间又必须建立起一种联系，而且具有可复制性。第三是服务器的交付，其实也被划拨进来。开发需要一台服务器，这个时候我们就很好的可以将计算力作为服务器的一种交付。
二、技术选型
技术选型现在有很多,kubernetes是比较风靡的一种，选择kubernetes即是建立了标准，它带来的利好就是成本下降。当我用跟别人一样的东西，我成本下降了，解决问题时的优势不言而喻。如果我选热度很高的项目，这个项目，首先对于我中小公司来说，我遇到问题至少可以在谷歌上，可以查到这个问题，有据可依。另外还考虑到的一个场景，即你需要的东西和你的选型是否契合，这也是非常值得关注的问题。此外，扩展性、生态发展、大公司的容易建立起生态，亦有前瞻性可循。
三、算力外卖
谈起算力外卖，李健津津乐道。据他介绍，饿了么做外卖，有好多东西容易要跟吃的结合起来。例如我们会议室可能叫“榴莲酥”。算力外卖我们需要的就是一个场景，例如说我们去饭店吃饭，这就是一个场景。再比如说一个开发环境，在使用完了这套环境之后就可以销毁了，或者我可以点一个套餐，点一套“环境”，好像我们去订外卖，购买一个套餐一样，包含很多内容。
在应用层面，李健把它描述得跟我们的胃口很像，包括各种不同类型的服务。所以会有这样一个box，box实际上可以把它抽象成一桌饭或者是一个外卖盒。在这里面我们可以看到，我们把每一个服务相互之间的调用，都通过domain去调用。而且这个box它有复制性，无论从这个模板里面创建出来box有多少，在每个box内部调不同服务的时候，它的域名是唯一的。
例如，从第一个服务调第二个服务的时候，第二个服务的域名是JOB，第一个服务调第二个服务的时候它从B就可以调用，这样就减少了开发人员复杂度。我们启用个服务的时候，自动给它生成唯一网络标识，可能是IP或者域名。想要更改我的配置，不需要更改它的配置，只需要把这个环境拉起来，这个应用就可以跑起来了。因为我的配置，我所对应那些服务，他们的网络标识是一样的，他们都是叫X。
四、基于kubernetes的拓展方案
李健演讲的最后一部分是“基于kubernetes的拓展方案”。其具体的实现就是用kubernetes去做底层的容器引擎。在里面可以看到，在一个Internal里面，包括domainl，pod我们可以在这个服务，它有自己的一个副本，做一个副的均衡。这些服务之间可能有依赖关系，例如A服务依赖B服务，如果B服务宕机，A服务要做一些处理。A服务依赖B服务，会有个启动数，我们在box里面也做了同样的事情。
当然从技术发展来讲，很多时候大家认为，新技术里面，不应该有依赖关系。但是我们现在遇到的问题，确实存在依赖。我们的服务业务在这个场景下，要推动标准化就一定要兼容开发的目前的一些项目或者它的习惯。
还有一些服务启停，那就是初始化。比如说有些服务完成之后会调另外一个pod进行初始化。还有一些公共服务，有些数据是需要传递的。我们就可以把外面的服务，通过内部标识转换到外部标识，我们内部标识实际上是永远是不变的，外面关系通过服务发现或者机制关联上来，这样就完全的不用考虑配置变更，或者服务发现等等问题了。
这个是我们的一个最简单的通过外卖的方式对我们服务的一个抽象。当然了我们在这个过程当中会考虑我们服务的规模，规模扩大后会发生什么问题。kubernetes依赖etcd，etcd，我们知道它实际上在kubelet场景下，它支持不了那么大规模，但是我们又对稳定性有一些要求。所以我们就只能说把它进行拆分，尽量的进行拆分。
如果我们人为的通过三个或者四个kubelet机群给它拆分了，如果拆得太细，资源利用率就会降低，有些机群可能饿死了，有些机群可能饱死了。我们就是通过一种方式，我们希望说让这些服务，kubelet是不同的etcd这个机群，有一个方式让服务可以在机群之间进行飘移，可以调度。这样既解决了资源效率的问题，又解决了可靠性的问题。
从上图的结构看来，除了黄色的部分，其他部分就是kubelet原先的一些组件。我们开发了一个类似于kubelet的API Server的服务。按照我们本来的想法，例如我现在调度完成之后，分两级调度，我们以为把资源调到A机群还是调到B机群就可以了，后来发现实际上很难做到。我们在现在使用的docker上加了一个小版本，小版本主要问题是，日志量很频繁的时候（毫秒级别）就会乱序，导致业务部门排查不下去。因此我们在docker里面增加了一个序号。
李健坦言，我们企业的软件环境，实际上是自己生长出来的，我们不可能因为一个开源软件更改现有的内容，我们希望通过某种方式让开源软件来适应现在的软件状态。这就是docker的一些监控，例如我们发现一些问题或者bug，都是通过监控来发现的。
此外，我们在容器管理当中，如果遇到一些问题，比如说将传统的业务进行容器化的时候，我们就进行改进。所有的东西都是在容器里面，internal进程是我们定制的，internal进程是切换技术层管理的一些目录和环境变量，另外一个是基础配置文件的一个宏代换替换。我们服务在跑这个的过程当中，有些服务迁移，以前是配置的，现在改成了容器。在环境变量里面，把这个配置从环境变量里面读，可能会产生一些成本。所以我们提供了一种方式，把变量写在里面，会根据容器这些环境变量自动替换这个配置。特别是在容器环境里面，如果这个容器没起来之前，不清楚它的IP，问题就必须在internal进程里面去解决。
本次WOT峰会讲师演讲稿件由51CTO采编整理，如欲了解更多，敬请登录WWW.51CTO.COM进行查看。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
