您的位置 首页 > 娱乐休闲

基于微服务架构,实解容器级DevOps平台的建设

本文作者为普元软件产品部主任架构师顾伟,文章分享了基于微服务架构,建设可以同时运行在公有云和私有云上的容器云平台的实践经验,以及容器技术栈和架构等。

导读:本文以“实践过程中问题与思考”为主体,与大家分享其中的过程和经验,希望大家在后续的工作中能够避免相关问题,形成更佳实践。

首先简单说下我们要做什么,不谈理念,不谈哲学,我们要做一款基于微服务架构,可以同时运行在公有云和私有云上的容器云平台,以DevOps为目标,提升协作效率,快速交付。

为什么选择阿里云

现在的公有云如雨后春笋,国外如AWS、Azure、Bluemix,国内如阿里云、腾讯云、DaoCloud、goodrain等,都可以给大家提供丰富的云基础设施和上层服务,那为什么选择阿里云呢?主要有三点想法:

1. 我们使用阿里云的服务已经有5年了,从企业级PaaS平台合作开始,再到帮助我们的一些客户逐步迁云,对阿里云的能力还是比较熟悉的。

2. 因为要做的是容器,国外AWS,Azure虽然有,但AWS在中国一直没“正规”数据中心(唯一的一个前几天还被查了),Azure是微软体系(也许是心里作祟,总感觉不对口...);而国内虽然一些公有云有容器能力,但规模普遍偏小;再者,阿里云反正也开始做容器了,说明人家底层还是有支持能力的。

3. 当然,还有一个做法,自建数据中心或租赁IDC,不过做事情还是得慢慢来(我们又不是暴发户...),不到一定规模,这个前期投入还是有点大的。

怎么用阿里云

有人问,在IT领域,现在跟10年前比,对技术人员或架构师要求有什么不同?

我是这么来看的,以前大多数是做加法 —— 每个领域就那几个产品或框架,需要的更多是集成能力;现在是要做减法,因为技术栈太多了(全栈工程师不好当呀...),到底选哪些,这往往是最考验能力的。

我们最终选择了Kubernetes+CoreOS+Docker的组合,当然少不了辅助的Etcd、Flannel...,大家可能会问,为什么不用ubuntu、ranchar啊,为什么不用OVS啊,其实我们都是有理由的,这篇文章里不是重点,私下交流。

那紧接着要做什么也就明了了,在阿里云的ECS上先跑CoreOS(Docker反正自带了),然后去部署Kubernetes那一整套,验证验证技术可行性吧,可以的话,再做分布式存储,然后支持DevOps,自动化运维,先后顺序也很好选。

没有问题是不可能的

大家可以到阿里云官网上去搜下Docker,或者KVM类似的,映入眼帘的是这个:

千万别气馁,因为都有CoreOS镜像了,不支持Docker谁信(其实阿里云还是蛮务实的,没有经过严格测试不敢说支持),好歹也得试一试,于是就先买了几台CoreOS机器,接下来做的一些事情就不那么顺利了:

1. 先做系统升级(默认版本比较低了,681.2.0 64位),那大家都知道外网流量很贵,所以最好搭个内部升级服务器,在升级后发现网络有问题,进不去,内部进入发现原因是网络没起来,这工作只有先手工做了(systemctlrestart )

2. 升级完了,最好的习惯是去打快照(当然,这个服务过些天就要收钱了,还挺贵的...),发现没打出来,这个问题排了好久,最后的原因是自作孽啊,删了个自认为没用的yunservice,后来想想也觉得自己幼稚了,都叫yun了,肯定是阿里云留下做事情的呀

3. kubernetes安装,一般来说有三种安装方式,命令型、服务型、容器型,技术成本考虑,最终我们先用了前两种的混合态,然后setup-network-enviroment辅助验证,还好没遇到大问题,容器间网络很快通了(我们用了container模式,端口映射出去)

4. 因为在VPC环境,我们使用了EIP,但IP资源实在是宝贵(20个),所以留了一个做堡垒机,其他的大部分给了计算节点,由kubernetes的service public IP消费了,这点告诉我们,宝贵资源大家前期一定要做好规划

5. 内部DNS能力,用了skyDNS,一个比较坑的问题,一定要用最新版本,之前哪怕是release版本都有问题,服务注册后进不去出不来的,反正挺诡异的,一直也没见说哪个版本修复的

6. 跑服务过程中遇到了棘手问题,大家都知道kubernetes的容器调度能力,会结合自身的一些分析,在运行时把pod做热迁,放到他认为合适的机器上,这就使得容器用宿主机本地磁盘不现实了,持久化数据没法迁移或共享呀(当然,有同学说可以通过label强制运行在某处,但好特性还是想用一用,不然什么都规划好,这和云的宗旨就貌合神离了),这怎么办?分布式存储是个好方案,但阿里的块存储服务还没发布,虽然我们一直是决定的自己搭,但那也是下个版本的事情了,这边先low了一下,只能先用NFS临时解决

最终架构和技术栈

问题就不详说了,这里再简单分享下我们的技术栈和架构,希望对大家有用。

刚才已经把容器技术栈给说了,接着就是容器里跑的微服务使用技术了:

1. springboot,让微服务编码、配置、部署、监控变得更简单

2. react+redux,让前端也可以微服务化

3. MetaCube(我们的产品),元数据,提供资源全图、驱动运营

4. Redmine,提供产品和服务管理

5. ElasticSearch、InfluxDB,运维监控能力

6. BPS(又是我们的产品),一体化的流程能力

其他还有好多,saltstack、gitlab、Jenkins、autoconfig、OAuth等等,不细说了。

平台是以DevOps为核心的,最终架构如下:

围绕统一接入,自动化协作,运营反馈等,建设了完整的企业级云平台,后面我会分模块一一介绍,大家先概览一下就可以了。

还有一些其他的能力建设

包括高可靠、高性能、灰度发布、熔断、APIGateway、自动化、安全控制…,大家有兴趣可以一起交流交流,共同进步。

注:文中有两处提及阿里云产品,特此注解

1,ECS内不支持Xen,KVM,但支持Docker

2,单独的块存储服务没有发布,但有云盘,是块存储

关于作者:

顾伟 普元信息主任架构师

顾伟 现任普元软件产品部主任架构师,毕业于东南大学,先后参与华为,中信银行,工商银行,中航信,阿里云,兴业银行等客户定制项目;参与并负责公司多款内部产品研发工作,长期致力于IT项目管理,总体设计,用户体验及咨询工作 擅长OSGI,eclipse插件,web前端,云计算,CI/CD等领域技术,对新技术有着浓厚的兴趣。

责任编辑: 鲁达

1.内容基于多重复合算法人工智能语言模型创作,旨在以深度学习研究为目的传播信息知识,内容观点与本网站无关,反馈举报请
2.仅供读者参考,本网站未对该内容进行证实,对其原创性、真实性、完整性、及时性不作任何保证;
3.本站属于非营利性站点无毒无广告,请读者放心使用!

“基于微服务架构,实解容器级DevOps平台的建设”边界阅读