一、龙腾出行的IT系统架构演变历程

2016年之前,我们有3种开发平台,java .net php,java和.net所占业务系统几乎各占一半,但.net平台在服务端架构方案比较欠缺,虽早已使用WCF进行分布式开发,但并不能跨平台,微软的闭源政策导致很多新技术不能友好兼容,在15年虽已实行开源政策,但时间还是太晚,且国内市场主流还是java系,因此决定全部转型java。
在dubbo时代,虽然开发业务效率有一定提升,但跟WCF一样,服务对平台敏感,难以简单复用,在提供对外服务时,都会以REST的方式提供出去,另外框架对服务侵入性较大,不能很好的支撑后续技术发展,期间我们也有根据thrift+zookeeper自研rpc框架,并且考虑支持多语言平台,但难度较高,团队规模也不允许,所以早早放弃,尽量使用开源平台,此时我们对docker、kubernetes进行调研,因此打开了另一扇大门,Kubernetes的功能足够炫!

二、利用kubernetes搭建容器云平台

kubernetes-容器编排的王者,容器云的首选方案,对虚拟化平台的革新功能:
– 资源调度
– 弹性伸缩、自动扩展
– 资源高利用率
– 负载均衡
– 资源基本监控
– 容灾备份
– 滚动更新
– 日志访问
– 自检和自愈

等等以上功能是在虚拟化平台中缺失或需要花时间实现的功能,但作为kubernetes平台的基础功能,大大简化了构建工作,提升开发运维效率,kubernetes各组件功能如图:

2017-2018年间IaaS/PaaS、docker、微服务、互联网架构等等各种概念侵袭,收到一波波的洗礼,我们完成了k8s从无到有并应用至生产,SOA/微服务的业务边界划分,并推行了前后端分离开发,奠定业务与人员架构基础,使前后端可并行开发,更好的支撑后续业务、技术发展,人员更精于自身专业方向。

目前我们的服务器在IDC环境中,已有VMware虚拟化平台,因此在虚拟机上搭建私有容器云是首选方案。
kubernetes 高可用采用官方推荐方案,整体搭建采用Keepalived+Nginx+Kubernetes+Calico,基于Kubeadm方式安装1.11.1版本,3Master+3Etcd+12Node节点,整体流程图:

高可用集群采用1主2热备,将keepalived 的VIP绑定到VM网卡上,当Master因故障宕机,另外两个master会根据keepalived配置的优先级接管VIP,从而起到灾备作用,另外将kube-proxy的serverIP换成Keepalived生成的VIP和自定义端口号,通过nginx转发至3个kube-apiserver,实现3master参与负载。
kubeadm-ha已经完全可以在生产环境使用,当master故障无法恢复时,可以快速加入一个新master节点,保障集群可靠性。

Etcd采用集群内3节点方案,kubeadm新版本可以友好支持Etcd-SSL的操作,当etcd故障时,通过kubeadm可以快速将新节点加入集群。
平台经过多次灾备演练,目前稳定可靠,如图大家应该比较熟悉:

我们采用ingress-nginx来取代VM上面的nginx,服务内部通讯采用k8s推荐的coredns,通过configmap方式配置DNS域名解析,取代原来挂载宿主机/etc/hosts方式。
外网访问,内网集群将Service以NodePort方式暴露端口,通过负载均衡器进行转发。

三、开发框架的变迁

根据kubernetes优秀的设计思想,开发也有相应的调整,新业务统一采用React+Spring Boot进行开发,因此我们的开发平台如下:

nodejs负责Web/H5前端

Android 、Ios 移动端

Java/Spring Boot 负责后端业务开发

一张图看懂开发架构:

在应用Spring Cloud Netflix套件时,Eureka安装在集群外的VM上,服务注册Eureka默认读取的是hostIP,在k8s上pod被分配的虚拟IP在集群外部无法访问,我们尝试过多种解决方案,例如挂载Volume方式,写入宿主机IP到容器内的env变量,最终还是统一将注册Eureka Clinet方法重写,将注册服务地址改为ingress配置的coredns域名,集群外部访问成功
在分布式微服务中,各服务都有一套独立的配置,Spring框架尤以面向接口编程思想贯穿整个项目工程,配置项众多,我们选用携程Apollo配置中心来替代properties,多个服务可共享一个namespace配置,解决复杂而繁琐的配置问题,配置中心已经上升到整个架构层面的作用

API统一接口文档采用去哪儿开源的Yapi,可私有部署,功能齐全,QA也可做接口自动化测试,测试集脚本语言支持Pre-Script,遵循javascript语法,如图:

四、devops流水线设计

根据上面的介绍,经过一定积累和沉淀后,我们开始设计CI(持续集成),CD(自动化部署),CI/CD的优势显而易见
– 解放了重复性劳动:
自动化部署工作可以解放集成、测试、部署等重复性劳动,而机器集成的频率明显比手工高很多。
– 更快地修复问题:
持续集成更早的获取变更,更早的进入测试,更早的发现问题,解决问题的成本显著下降。
– 更快的交付成果:
更早发现错误减少解决错误所需的工作量。集成服务器在构建环节发现错误可以及时通知开发人员修复。集成服务器在部署环节发现错误可以回退到上一版本,服务器始终有一个可用的版本。
– 减少手工的错误:
在重复性动作上,人容易犯错,而机器犯错的几率几乎为零。
– 减少了等待时间:
缩短了从开发、集成、测试、部署各个环节的时间,从而也就缩短了中间可以出现的等待时机。持续集成,意味着开发、集成、测试、部署也得以持续。

代码管理工具我们一直在用gitlab,经过研究,gitlab在8.0+版本就已经集成了CI/CD,可以帮助我们快速实施自动化,相比jenkins,gitlab-ci更加轻便,只需要在项目工程根目录创建.gitlab-ci.yml文件,写好job脚本即可,在服务器安装gitlab-runner工具,帮助执行job,一张图看懂我们基于k8s的CI/CD Pipeline

借助gitlab-runner,我们已实现多个devops流程,包括NodeJs、Spring Mvc,以及在VM虚拟机上的CI/CD


如部署遇到问题,可快速手工触发CI/CD,回滚上一个版本,保障线上始终有一个版本可用。CI/CD 流程代码示例:

stages :
 - build_test #测试CI
 - deploy_k8s_test #测试CD
 - build_prod #生产CI
 - deploy_k8s_prod #生产CD

#测试CI
build_test_job:
 stage : build_test
 script:
  - mvn clean install
  - cd target
  - docker build -f classes/app.dockerfile -t registry/maven-project:$CI_COMMIT_SHA .
 artifacts :
  paths :
    - target/classes/deploy.k8s.yaml
 tags :
  - runnerHost
 only :
  - master

 #测试CD
 deploy_k8s_test_job:
  stage : deploy_k8s_test
  before_script :
  - docker push registry/maven-project:$CI_COMMIT_SHA
  script:  |
  kubectl apply -f deploy.k8s.yaml
  kubectl describe -f  deploy.k8s.yaml
  after_script :
  - pwd
  tags :
  - runnerHost
  only :
  - master

五、运维监控平台

k8s在1.13+版本中已经剔除了heapster+influxdb作为默认监控工具,主推promerthues,promerthues可以做到代码级的监控,我们在各虚机、中间件、应用程序中使用工具收集资源消耗信息
grafana可作为大数据展示平台,实时查看各项资源运营情况

Prometheus也提供java开发包,可以做到代码级统计,当服务响应报错或时间过长,可触发告警,通知相关开发人员查看原因

六、平台整体架构

私有容器云和devops主流程已经实现,配合promethues监控,基础设施层形成闭环,这是从无到有的过程,整体架构一张图可以看懂:

总结:目前的框架都是原生应用,利用了各家的优秀特性,我们并没有针对性改造框架,原生功能足够满足团队业务需求;有许多地方还需要深入研究和应用,完善基础设施层,例如监控目标、告警规则、Service Mesh如何将服务间请求下放到基础设施层、CI/CD的持续完善,金丝雀发布等等

Q&A

Q:部署从开发环境到测试环境,以及最终到生产环境,可以用 helm 来打包应用并部署,但部署到各个环境的配置文件,应该怎么管理呢?
A: 我们还没有用到Helm去管理包,如果是应用程序部署可以考虑携程Apollo做配置中心,各环境无缝切换
Q:k8s本身技术框架带来的问题在生产环境中有碰到拿着,请举几个例子。
A:k8s如果出问题带来的都是雪崩效应,例如网络Calico、存储Etcd出现故障是灾难性的,所以要做到高可用才能稳定生产
Q:一个开发人员想在开发环境部署一个服务,他必须要懂k8s,去写那些yaml吗,有什么易用的可视化平台
A;yaml有一套语法体系,非常简单,可以搜一下相关资料,主要是理解k8s的相关原理,根据服务要求编写配置文件,如果运维比较成熟,这些yaml可以交给他们来编写
Q:公司环境较复杂:包含java项目,php项目。java项目目前大多是spring boot框架,php
thiphpnkA框,项目架构并不复杂,有少许java项目需要用redis到memcac等hed、缓存机制。最大问题的是多而项目如何请问应该如何较好的依托k8s顺利架构,将架众管持续理项目,集成?
A: 我们的redis这一类中间件还放在VM上,目前尚未打算搬移到k8s上,k8s+docker天然是跨平台的,php也可以支持
Q: 应用有是否有状虑使用,用的什么存储解决方案?
A: 我们提倡无状态部署,目前所有应用服务都是无状态,有状态服务存储可以考虑nfs
Q:用二进制安装可以不,kubeadm会有升级些问题,默认的iptables不太好吧。现在是ipvs。
A:二进制也可以,比较稳定,kube升级adm目前我们是另外搭集群
Q:calico网络你们如何解决跨中心的网络通信,BGP只能在同一个交换机才能学
A:我们目前还没跨机房通讯,不过etcd需要高速网络才能数据同步
Q: 请问你们k8集群现在有多少流量,有没有上istio?
A:应用接口的流量月千万左右
Q:服监控 务和基服务监控器这块的取舍,现在监控都是用prometheus ?
A:prometheus是CN旗下仅次于k8s的项目,对应用程序比较友好,跟zabbix各有特色
Q:请问你们是创业问团队还是校园是团队?考虑k8s机缘是?对于k8来源源
生态所存在的不足,如安全问题是考虑怎么的
A:算是创业团队,k8s是在内网运行,并无安全顾虑,k8s 生态已经非常强大
Q:k8集群你们为什么没有部实体机在署上?
A:虚拟机和实体机都行,我们实体机数量有限,包括中间件那些,做高可用会用占用比较多的虚拟机
分享嘉宾:周伟