基于微服务架构，实解容器级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 systemd-networkd.service） 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等领域技术，对新技术有着浓厚的兴趣。 如有技术问题，欢迎与文章作者沟通互动，如下为作者微信二维码：

12-微服务技术栈（高级）：容器引擎Docker 在前面的学习中，我们掌握了微服务的服务注册与发现(nacos)、配置中心(nacos)、远程服务调用(feign)、网关(gateway)，同时借助Idea编译工具多次完成本地服务启动、部署和验证。在微服务架构中，不会再像传统那样单个单个部署服务器，而是会借助Docker进行批量的容器化部署。
如何灵活的更改微服务容器运行时的堆内存大小及环境变量 SpringBoot微服务打包容器启动运行时就会加载打包时设置的Jvm参数，当上线后监控到内存不足时需要调整参数时就要重新打包升级版本等一系列繁琐操作，那能不能只需要更改配置重启就能解决问题呢
2022 云原生总结：容器智能化、微服务开源普惠、Serverless 爆发，“用好云”成关键词 在第三届云原生实战峰会期间，阿里云智能云原生应用平台产品负责人李国强接受媒体采访，为我们解读云原生的最新发展与阿里云在云原生领域的最新实践。