推荐微网站建设,wordpress原创meta,建设工程服务平台,hhvm wordpress作者简介#xff1a; 章烨明#xff0c;杏仁医生CTO。中年程序员#xff0c;关注各种技术和团队管理。本文首发杏仁医生技术站 1. 创业公司的技术挑战
托尔斯泰说#xff1a;“幸福的家庭都是相同的#xff0c;不幸的家庭各有各的不幸。”互联网创业公司也一样。大部分互… 作者简介 章烨明杏仁医生CTO。中年程序员关注各种技术和团队管理。本文首发杏仁医生技术站 1. 创业公司的技术挑战
托尔斯泰说“幸福的家庭都是相同的不幸的家庭各有各的不幸。”互联网创业公司也一样。大部分互联网创业公司都会碰到以下几个技术挑战。
如何快速、低成本的搭建系统同时确保安全稳定如何快速的构建和发布应用满足业务需求如何提高团队开发效率确保开发质量
这个列表肯定不完整但这三个应该是创业公司技术团队都会面临的共通的问题。当然杏仁不能说完全解决了这几个问题但还是取得了一些进展。我们接下来简单介绍下我们杏仁是怎么应对这些挑战的以及容器又可以带来什么
该系列文章会分为三篇。第一篇介绍容器化之前杏仁技术架构的发展历史。第二篇介绍容器以及杏仁的容器化方案。第三篇最后总结为什么我们认为创业公司应该用容器以及为什么容器可以帮助我们应对这三个挑战。
2. 杏仁早期
在 2012 年以前大部分互联网公司包括创业公司都是直接购买服务器租用 IDC 机房的机架部署的。应用是直接运行在物理机上的要扩展必须购买新服务器。IDC 经常出各种故障如果碰到 IDC 迁移的话就更痛苦必须半夜搬机器天亮前上线。总之对创业公司的成本、服务稳定性、工作效率都是有很大的消耗。
不过杏仁医生很幸运正好赶上了公有云的成熟所以一开始就是基于公有云搭建的。杏仁医生最早期的架构如下 这个架构非常简单其中负载平衡、数据库都是基于腾讯云的。然后腾讯云也提供了一些基础的监控、告警和安全服务。然后就是两个应用一个移动后端 API一个运营平台都是基于 Play 的 Scala 应用。
很多人可能会好奇为什么选择 ScalaPlay 进行开发毕竟 Scala 在国内应该用的不多。这里一方面因为杏仁医生是继承了看处方的架构当初看处方就是基于 ScalaPlay 开发的 团队对这一套方案比较熟悉。我们需要快速的构建杏仁医生自然就会选择最熟悉的语言和框架。而且对于中小规模的应用ScalaPlay 的开发效率的确非常高。Scala 本身的表达能力非常强是一门很有意思的语言。很多好学的工程师也会对新的语言也会比较感兴趣。
3. 应用拆分和CICD
经过一年多快速演进整个应用越来越庞杂。所以我们对应用进行了拆分并且随着业务扩张应用也越来越多例如 HIS、CRM 等。所以我们的架构变成了这个样子。 这时 Scala 最大的问题开始体现出来了那就是编译速度的问题。那时候我们的应用部署方式也很原始必须登陆服务器运行一个 Shell 脚本它会拉取代码然后编译、打包、运行整个过程需要耗费510分钟。而我们 API 应用的节点后来增加到 5、6 台即使两台同时发布也需要 20 分钟才能全部发布完成。如果发布后出了问题那就吐血了因为回滚也是一样的流程又需要 20 分钟。
有一次我们做了一个送 Apple Watch 的活动半夜 12 点开始。我们出了个很低级的 BUG活动一开始就蹭蹭蹭的一分钟送好几个 Apple Watch。我们创业公司也没多少钱每一个都是白花花的银子心痛啊。修复很简单但发布或者回滚都得先编译太慢了于是我们一狠心把服务器给停了几分钟后才部署上了新的代码。
这是我们觉得必须要有一个自动化的发布系统了。其实在几年以前发布都是需要运维执行的研发提交给运维运维手动部署。那自然发布不可能很频繁并且对开发和运维都是很大的负担。但渐渐的敏捷和 Devops 的文化成为主流持续集成和发布CI/CD成为一项基础设施。
我们第一版 CI/CD 很简单是基于 Jenkins 的通过脚本进行编译、打包然后拷贝到服务器上发布。因为只要打包一次即可缓解了部署慢的问题。但还是存在几个问题。
首先没有应用仓库。打包是一次性的部署的时候会备份当前应用目录用于回滚所以只能回滚到上一个版本。其次健康检比较简单只能检测应用是否启动。我们遇到过应用启动了测活也没问题但服务还是有严重问题、基本不可用的情况。最后不支持灰度发布出问题只能回滚。
期间我们有一次较大的故障也是因为这几个因素花了很长时间才恢复。痛定思痛于是我们又开发了 Frigate 发布系统它的架构大致如下图。 Frigate 有一个应用仓库即 App Repository。应用仓库会保存发布的应用版本回滚的时候可以指定版本。Watcher 组建实现了比较强大的应用检测功能。除了一般的 HTTP 检测还可以从日志、监控里获取数据可以根据异常数、错误率等进行进一步的健康检测。Frigate 支持分组和分阶段发布。例如现发布2台机器然后健康检查或者中间可以有一些人工检查然后再发布剩余的机器。
后来回头看Frigate 虽然没有使用容器但其实是实现了容器编排的很多功能。Frigate 发布的截图如下这是基于 Jenkins Pipeline 的。 4. 微服务化
系统多了依赖复杂、数据没有隔离、逻辑重复接下来一个必然的方向就是微服务。关于微服务我们公众号有两篇文章乐高式微服务化改造上、乐高式微服务化改造下对此有比较详细的分析说明这里就简单介绍一下。
我们的服务注册和发现是基于 Consul 的负载平衡是通过 Nginx 实现的。下图是整个服务注册和发现的过程 有几点是值得一提的。
首先我们的微服务是基于 HTTP 和 Json 的没有采用二进制的协议如 Protobuf、Thrift 等。其实 HTTP 和二进制协议的性能差别并没有很多人想的那么大一般也就2、3倍的差距没有亲测。对大部分企业这个差别根本就不是瓶颈特别是现在还有 HTTP2。如果真的有需要还可以在 HTTP2 上跑二进制协议通过框架在服务端和客户端加一层就可以实现。
其次我们的微服务对应用是无侵入的。我们没有采用常见的 Dubbo、SpringCloud 框架。一方面我们服务调用方有 Java 应用也有 Scala 应用要接入还是要花点功夫。另一方面我们认为微服务框架发展的未来方向是非侵入性的独立的微服务基础设施层。其实这和容器编排的理念是一致的并且最近提出的 Service Mesh 概念就是进一步的延伸我们认为这才是微服务的未来。
最后我们每个微服务都会生成一个 SDK便于调用方调用。SDK 集成了熔断、异步、分布式追逐开发中等功能。
搭建了微服务基础框架后我们开发了好几个微服务有业务的例如订单、预约等有基础设施的例如推送、短信等。当然其实有些并不算“微”。
但是我们发现整个体系依然存在不少问题
基于云服务成本低了效率高了。但运维还是面向资源的并且资源利用率不高。有了持续集成和部署的能力。但新增节点、新建服务等依然需要大量人工运维并且扩展并不方便。实践微服务改进了应用架构。但依赖管理、监控等尚未完善稳定性仍然不够。
5. 容器是什么
上面我们简单说明了杏仁容器化之前的架构发展。下面我们就来谈谈容器。
2013 年 Docker 横空出世到 2015 年已经渐渐进入大家的视野。容器当然不一定是 Docker而且容器现在也是有标准的。但一说容器大家肯定会想到 Docker。所以我们这里说的容器主要就是指 Docker。
容器到底是什么呢顾名思义容器就是用来装东西的。在这里它用来装的就是应用程序。容器的特点简单说就那么四点
容器是自包含的它打包了应用程序及其所有依赖可以直接运行。以前应用程序的依赖管理一直是个大问题即使像 RPM 、Maven、Ansible 等都能解决一部分问题但并没有一个所有应用程序通用的标准机制直到容器出现。容器是可移植的可以在几乎任何地方以相同的方式运行。这就可以确保应用在开发环境、测试环境、生产环境等都有完全一样的运行环境。容器是互相隔离的同一主机上运行的多个容器不会互相影响。即一个容器中运行的应用程序是访问不到其他容器的资源的进程、网络、文件、用户等除非配置为共享的资源。容器是轻量级的体现在容器的秒级启动并且占用资源很少。
容器能做的很多事情虚拟机也能做那它们有什么区别呢下面这张图是 Docker 官网的截图很好的说明了两者的区别。 但最根本的差别其实就是最后一点轻量。很多人可能觉得这只是一个简单的差别但其实不是。因为就是这一点使得容器可以成为一种 标准化的应用发布方式。
上个世纪 5、60 年代集装箱刚出现看上去也只是简单的差别也没有什么技术含量。但集装箱提供了一个标准化的物流方式全球的海陆空运输、码头装卸等围绕集装箱形成了整个一个高效的物流体系。最终改变了世界贸易促成了全球化。
所以容器这个标准化的应用发布方式最终会影响上层的整个应用架构。最终围绕容器会建立一套完整应用架构体系带来革命性的改变。现在其实已经可以看到一点端倪了Kubernetes 基本已经成为标准不久前 Google 还发布了 Istio 这个 Service Mesh 工具进一步把微服务的基础架构也抽象了出来。
6. 容器编排是什么
光有能装应用的容器还不够如果还是人工管理那么多容器那也发挥不出容器的优势。所以我们需要一个容器编排系统。容器编排能提供以下功能
应用调度应用部署、无缝升级、弹性扩展、自愈等。资源管理内存、CPU、存储空间、网络等。服务管理命名空间、负载均衡、健康检查等。以及很多其他功能如日志、监控、认证、授权等。
容器编排领域最主要的三个系统是 Docker Swarm、Kubernetes 以及 Marathon/Mesos。
Swarm 是 Docker 官方的方案优点就是简单缺点是太简单了。
然后是 Google 的 Kubernetes也叫 K8s。Kubernetes 最近一年大放光彩几乎统治了容器编排领域就连 Docker 官方不久前也宣布了支持 Kubernetes 。它的优势就是有大厂支持而且 Google 是把它作为战略来布局的你可以把它想象成当年的 Android它的社区也非常火爆。
技术上Kubernetes 是一个集成的方案设计非常优秀可以说是分布式系统的设计典范Google 在这方面毕竟有很深入的经验。缺点就是有点复杂而且在今年之前它还是存在不少问题包括性能问题、大版本的兼容性、部署复杂等当然现在已经基本解决了。
Mesos 在 Docker 之前就有了本身做的是分布式系统的资源管理Mesos 很灵活上面可以支持各种系统包括 Spark 等。Marathon 则是基于 Mesos 实现了编排的功能。
我们是去年年中考虑容器化的我们最后选择的方案是 Marathon/Mesos。原因一方面是之前 Jenkins 容器化已经用到了 Marathon/Mesos有些经验。另一方面是该方案便于和当前的架构整合。Kubernetes 太过复杂迁移的话对架构改动太大。
7. 杏仁的容器化
我们容器化之后的架构是这样的 所有的应用都以容器的方式运行在 Mesos Slave 上Mesos Master 统一管理 Mesos Slave 服务器。Marathon 通过 Mesos 调度容器进行发布、升级、扩容等。Calico 是 Docker 的网络解决方案实现了一个容器一个 IP 以及容器之间的互联。而右上角部分我们基本保留了我们之前的微服务架构只是用于服务发现和注册的 Consul Agent 替换成了 Registrator。
同时我们的 CI/CD 也相应的做了调整。 Jenkins 自身现在也是基于容器的会在 Mesos Slave 的容器里进行编译和打包。应用会被打包成的 Docker 镜像上传到我们的镜像仓库 Harbor 里。部署时Jenkins 调用 Marathon 的接口进行部署Marathon 则从 Mesos 申请资源。部署时 Mesos 会从 Harbor 下载相应的应用镜像并根据配置运行。
有了这套系统我们创建应用、扩展应用就很简单了。创建应用时首先通过 Dockerfile 和 Jenkins 创建镜像然后在 Marathon 界面上只需要准备一个 Json 配置也可以通过 Form 配置指定资源、实例数、镜像、网络、健康检查、环境变量等就可以很快上线一个新应用。 有时候我们要准备一个秒杀活动或者推送几百万用户需要增加应用实例也只要在 Marathon 界面调整一个数字就可以了。 除了容器编排和 CI/CD还有两个很基础的东西一个是基于 ELK 的统一日志平台、另一个是基于 Open-Falcon、StatsD、Graphite、Grafana 的 监控告警平台。大致结构如下具体实现以后有机会再专门写文章介绍这里就不详述了。 最终我们的整个平台的组成是这样的 8. 容器化总结
到这里为止这些就是杏仁目前的基础平台的架构。通过这套系统我们提升了资源利用率刚刚迁移到容器化环境的时候我们只用了原来大约 6、70% 的云服务器。并且我们大大加强了我们的自动化运维的能力完善了服务监控。
但是这套系统也存在不少问题。
新增服务器节点还是需要一些手工操作。容器、环境等的配置都是分散在各处缺乏有效的管理。对有状态应用支持不好。系统存在一些冗余例如有 Zookeeper、有 Etcd 还有 Consul。不支持自动扩容。部分基础设施没有容器化。
未来我们会继续进化也许等时机成熟了也不排除会迁移到公有云的容器服务或者自建 Kubernetes 集群。
