千丁互联吧 关注:16贴子:663
  • 3回复贴,共1

千丁云背后的三朵云

只看楼主收藏回复

云计算这一概念被提出后,一直在业界受到持续的关注、研究及应用。部分专家学者将云计算分为三层:IaaS、PaaS、SaaS,相比较而言,IaaS、SaaS容易理解,而PaaS则相对模糊,在业界分歧较大。简单而言,IaaS提供计算、存储、网络能力支撑整个计算机系统运行,SaaS提供面向多租户的应用系统,而PaaS则是面向应用提供丰富的运行时环境,如不同语言、数据库、中间件等环境。为了减少不必要的分歧,结合DevOps实践,千丁云研发小组定义了容器云、研发云、监控云三个产品,简单来说容器云负责提供程序运行时环境,研发云负责程序编译、部署,而监控云则负责整个系统运行时监控。


1楼2020-04-16 14:08回复
    1.1 容器云
    云计算技术兴起之初,以整合计算、存储、网络等虚拟化技术的OpenStack做为第一代标志产物,被国内外各大公有云厂商所使用,但由于OpenStack设计复杂等问题,各大厂商均以此做为基础进行改进。不久之后,随着以Docker做为代表的容器技术兴起,以及Google将Kubernetes贡献到开源社区,业界逐渐把目光聚焦到基于Kubernetes及Docker构建的容器云上,并将之称之为第二代云计算技术,这两者各有优缺点,并非简单的替代关系,对此千丁云研发小组结合业务特点对这两种技术在千丁互联的应用做了详细的评估。

    综合而言,OpenStack更适合公有云厂商使用,提供面向多租户,网络、存储、计算隔离较好的公有云IaaS环境,用户可以基于这种环境部署应用、数据库及各种中间件。而Kubernetes则更适合企业内部,面向应用提供运行时环境,并不适合部署数据库、中间件等系统。结合千丁互联的业务场景,千丁云研发小组选择了Kubernetes做为云计算基础环境,将应用程序部署于其上,而数据库、中间件等对可靠性要求较高、数据需要持久化存储的系统,仍然采用物理机进行部署。与此同时,先后与华为云、京东云、UCloud建立了良好的合作关系,不断深化合作,使得容器云快速上线。至今生产环境已经有100余个系统运行在基于Kubernetes的容器云环境中。


    2楼2020-04-16 14:08
    回复
      1.2 研发云
      通常系统研发与上线、部署通常分属于研发和运维等不同部门,部门间的协同经常会导致上线时间长、失败率高,这也是业界经常出现的问题。为了解决这一问题,提高研发效能,千丁云研发小组参照业界流行的DevOps工作模式,开发了一套全新的研发云系统实现CI/CD无运维。

      编译程序
      CI/CD方面,千丁云研发小组之前使用Jenkins进行构建,但Jenkins仅仅适合编译,而不适合发布。研发云的编译过程他们仍然使用Jenkins,调用Jenkins API进行编译,之前他们的Jenkins编译脚本采用Shell脚本,为了实现多语言环境的Jenkins编译,在研发云的Jenkins环境上,他们启用了Jenkins 2.0之后出现的Pipeline,使用Groovy开发编译脚本,每个Stage根据不同的编译器及版本,在响应的Docker镜像中运行,避免了在一个Jenkins编译主机上安装不同编译环境所引起的环境冲突问题。同时,他们将编译脚本放到Git上,相同语言的项目对应同一个编译脚本,当需要修改编译过程时,只需要全局修改即可。程序编译通过后,将编译好的程序打包成Docker镜像,推送至Docker Hub中,运行时,直接调用Kubernetes API运行指定的镜像。
      生产环境上运行的程序,不同于开发、测试环境,需要考虑的更多,如实现资源配额管理、运行时修改配置、系统回滚、蓝绿发布、灰度发布等等。研发云上,他们通过启动系统时设定资源配额的方式,将配额设定传递给Kubernetes,由Kubernetes来管理运行时程序所能使用的计算资源。在运行时修改配置方面,研发云集成了携程开源被业界广泛使用的Apollo配置中心,通过API方式修改程序配置。在蓝绿发布、灰度发布方面,千丁云研发小组正与华为云合作,将Service Mesh的最流行实现方案Istio引入研发云。

      Apollo配置

      运行时资源配置


      3楼2020-04-16 14:09
      回复
        1.3 监控云
        程序的稳定运行离不开监控,监控云产品就是为实现这一目标所设立。一般来讲,监控主要从基础设施监控、应用监控、用户端监控几个方面进行。对于基础设施监控,千丁云研发小组使用业界比较流行的Prometheus+AlertManager进行监控。对于应用程序监控,主要涉及Log、Metrics、Trace几方面,为此他们评估了业界几个主流的开源产品PinPoint、SkyWalking、ElasticAPM。

        由于PinPoint部署过于复杂,需要HBase环境,首先排除PinPoint。SkyWalking告警规则文档描述不清,似乎不能运行时修改告警规则。ElasticAPM不支持Dubbo,但代码结构清晰,监控数据存储在ElasticSearch中,容易扩展开发,同时Elastic APM可以与kibana结合,利用kibana丰富的可视化功能,方便的展示应用运行时信息。结合实际情况,最终他们选择了ElasticAPM做为APM,整个APM架构如下:

        为了实现发送告警通知,他们参考Prometheus的PromQL查询语言实现了一套新的查询表达式,方便系统研发使用来进行告警规则设置。比如:avg(http{appname="qdp-polaris-server"} by url range 5m)> 2000,计算5分钟内qdp-polaris-server系统各个http接口的平均响应时间,如果超过2000ms则产生报警。相当于SQL中的select avg(响应时间) from table where timestamp between now() - 5m and now() group by url。值得注意的是,Skywalking 6.5.0后也实现了运行时动态配置告警规则,关于Skywalking他们则将持续关注。
        用户端监控方面,目前他们使用监控宝进行监控,周期性查看来自用户端的性能报告来优化系统。


        4楼2020-04-16 14:09
        回复