头条技术号：实战架构

交流邮箱：[email protected]

本文主要讲述：

基于阿里云自建kubernetes集群与微服务的生产实践系列-1：整体架构-1

目录：

(1).demo演示地址

(2).概述

(3).大纲

3.1.包含从传统服务架构到容器化&微服务架构的整个过程

3.2.包含3.1中各个环节的细节探究与实践

(4).基于阿里云的整体混合架构

4.1.混合架构概览

4.2.一个数据请求的完整周期

4.2.1.用户请求->服务域名->阿里云负载均衡

4.2.2.阿里云负载均衡->openresty->阿里云负载均衡

4.2.3.阿里云负载均衡-> 真实服务

4.2.3.1.容器化服务路径

4.2.3.2.非容器化服务路径

(5)可观察性/可视化/报警

5.1.可观察性概览

5.2.app服务可观察性

5.3.ingress可观察性

5.4.k8s可观察性

5.5.openresty可观察性

5.6.redis可观察性

5.7.rocketmq可观察性

5.8.特殊业务可观察性

(6).容器化生产实践相关

(7).开发框架简述

7.1.相关技术选型

7.2.code demo

7.2.1.allinone-demo工程结构

7.2.2.code示例

7.2.2.1.allinoneRPCApplication示例

7.2.2.2.allinoneWebApplication示例

7.2.2.3.apollo配置中心

(8).笔者容器化相关实战github

8.1.提供一个低成本容器化所有组件的最佳实践

8.2.笔者生产实践中使用/制作的jdk官方镜像

8.3.本系列文章所涉及的相关资源的github备份

8.4.笔者生产实践中的openresty高性能配置

(9).小结/感慨

(1).demo演示地址

注意，如果访问8080提示403，有可能是你的IP触发了笔者openresty的防封逻辑，请关注笔者微信公众号后发消息给笔者，将你的IP提供给笔者进行配置。

目前可开放的演示地址：

apollo(容器化):

http://dev.apollo-portal.future.com:8080/signin

User: guest

Password: guest

grafana(容器化):

http://monitor-app.future.com:8080/

User: guest

Password: guest

需要配置host:

39.98.43.48 dev.apollo-portal.future.com

39.98.43.48 monitor-app.future.com

(2).概述

容器化技术与微服务体系的结合是未来后端的总体趋势，可以极大的简化开发流程与IT技术成本；

作为coder，不论是身处哪一个领域，都非常有必要了解容器化&微服务下的后端架构；

本系列文章由此而来，笔者将系统讲述亲身负责的kubernetes容器化&微服务的生产实践；

(3).大纲

3.1.包含从传统服务架构到容器化&微服务架构的整个过程

调研各类微服务技术体系 ->

确认技术选型 ->

自研适应kubernetes容器化的微服务框caf ->

服务迁移到微服务框架 ->

基于阿里云自建多可用区的kubernetes集群 ->

讨论&确认容器化过度方案&最终方案 ->

业务服务容器化 ->

基础组件/基础服务容器化；

贯穿始终的体系可观察化(grafana/prometheus)；

3.2.包含3.1中各个环节的细节探究与实践

(4).基于阿里云的整体混合架构

4.1.混合架构概览

高清图片请从此处下载：

https://github.com/hepyu/kubernetes-microsvc-product-practice/blob/master/images/%E5%9F%BA%E4%BA%8E%E9%98%BF%E9%87%8C%E4%BA%91%E8%87%AA%E5%BB%BAkubernetes%E9%9B%86%E7%BE%A4%E4%B8%8E%E5%BE%AE%E6%9C%8D%E5%8A%A1%E7%9A%84%E7%94%9F%E4%BA%A7%E5%AE%9E%E8%B7%B5%E7%B3%BB%E5%88%97-1%EF%BC%9A%E6%95%B4%E4%BD%93%E6%9E%B6%E6%9E%84-1.jpg

图例说明：

蓝色：表示使用阿里云提供的服务，如rds,镜像服务等。

绿色：表示已经容器化的部分。

橘色：表示最终要容器化的部分。

混合架构的含义：

是一个过渡阶段：指非容器化服务与容器化服务共存的架构，当然，最终非容器化的部分会全部容器化(图例中橘色部分)。

整个架构基于阿里云，公有云提供了很多实用/高可用的基础设施，极大的节约了成本/操作复杂性。

4.2.一个数据请求的完整周期

对照3.1.中的混合架构图。

4.2.1.用户请求->服务域名->阿里云负载均衡

用户请求通过域名进入，DNS将域名解析到阿里云的负载均衡；

在阿里云上可以直接配置域名的DNS解析，将负载均衡的公网IP配置到DNS上，如果一个负载均衡不够，多配置几个。

4.2.2.阿里云负载均衡->openresty->阿里云负载均衡

在使用阿里云负载均衡时，很多时候负载均衡会直接挂载到后端的业务服务上；

我们并没有采用这种方式，而是中间又加了一层openresty，原因在于openresty可以额外处理很多feature，比如rewrite,prometheus监控(流量/qps等)，特别是IP防封逻辑，而这些feature在阿里云负载均衡层面是不具备可操作性的；

openresty负责前述的各类feature处理和流量转发，再次转发到阿里云负载均衡；这时的负载均衡将直接挂载真实的后端服务，且这时的负载均衡分为两类，一类是挂载K8S容器内的服务，另一类是挂载非容器化服务。

4.2.3.阿里云负载均衡-> 真实服务

这里分两条路径，容器化的服务和非容器化的服务，其处理路径是不同的；

4.2.3.1.容器化服务路径

阿里云负载均衡通过K8S集群内部的loadBalancer组件桥接到K8S内的ingress-nginx反向代理，再由ingress-nginx反向代理到容器内部的服务(k8s-service->k8s-pod)。

即：阿里云负载均衡-> k8s-loadBalancer-> k8s-ingress-nginx -> k8s-service -> k8s-pod（container）。

4.2.3.2.非容器化服务路径

这个就很简单了，很传统做法一样，直接挂载实际服务(在阿里云的负载均衡处配置)。

(5)可观察性/可视化/报警

容器化时代下的微服务体系，对整个架构的可观察性与可视化的要求极高，否则很难找到对应的问题触发点。

举一个例子，当容器内部的某个pod的p99延迟突然飚增到10秒，那么如何判断诱因？除了传统的诱因外，在容器化的前提之下，还要考虑pod驱逐，cpu弹性伸缩等容器相关诱因。

再如，当基础服务/组件容器化后，我们如何评估其在容器内部的健康状态，可观察性和可视化都是极其重要的手段，在一定意义上可以说是唯一手段。

我们使用grafana/prometheus做容器化/非容器化的可观察性，可视化，及报警的手段，进行全方位无死角的可观察度量。

使用钉钉连接k8s-prometheus的alert报警组件，这就是基于阿里云构建容器&微服务的好处，这些零七八碎的东西非常磨人的。

注：我们目前生产环境的grafana/prometheus实际上还是存在一些低优先级的死角度量。

5.1.可观察性概览

App: 服务可观察性

Ingress: ingress-nginx可观察性

K8s: k8s集群可观察性

Nginx: openresty可观察性

Redis: redis可观察性，包含cluster, standalone, 哨兵等模式。

5.2.app服务可观察性

dashboard举例：

5.3.ingress可观察性

5.4.k8s可观察性

Cluster举例：

5.5.openresty可观察性

Dashboard举例：

5.6.redis可观察性

Cluster举例：

5.7.rocketmq可观察性

mq集群全维度举例：

5.8.特殊业务可观察性

开发框架不覆盖特殊业务的可观察性，需要业务方自行实现：

以oss上传服务为例：

还有阿里云rds, elasticsearch，consul等组件的可观察性，这里不再一一罗列，后序都会另行开文详细陈述。

(6).容器化生产实践相关

这个会在后续的系列文章中逐步提供；由于内容太多，本文不做陈述。

(7).开发框架简述

7.1.相关技术选型

我们并没有采用springcloud全家桶，一方面没有必要(复杂度考量)，另一方面我们关注的是简单极致以及性能的高效；

最终我们选择基于现有成熟的技术自研一套基于注解的开发框架；

RPC: 微博的motan

注册中心：zookeeper

配置中心: 携程的apollo

可观察性/可视化： prometheus

限流：阿里的sentinel

JVM健康检查：spring-boot-starter-actuator

mq: rocketmq

search: elasticsearch

缓存：redis

DB: mysql

DB连接池：阿里druid

链路追踪：skywalking

包含但不仅仅限于上述选型。

7.2.code demo

虽然是我负责框架开发，但是我无权代码开源，只能申述思想和demoCode，本文这里只展示一下demo，具体细节后续另行开文。

7.2.1.allinone-demo工程结构

以allinone-demo举例：

allinone-api: motanApi接口。

allinone-service: rpc工程，motain-provider。

allinone-web: web工程，motain-consumer。

7.2.2.code示例

allinone-demo中使用了所有的基础组件/基础服务；

完全基于注解；

遵循惯例重于配置的原则；

7.2.2.1.allinoneRPCApplication示例

业务开发者使用任何组件时只需要通过注解开启，相关的配置全部在apollo，通过apollo自动注入。

使用时直接使用注解Autowired/Resource即可，但要注意名字，和注解中的声明要对应，这里便是遵循了惯例重于配置的原则。

7.2.2.2.allinoneWebApplication示例

code也是类似的，完全基于注解，全方位解放业务开发者，只需关注业务即可。

7.2.2.3.apollo配置中心

这里简单陈述，实际上apollo的使用也需要规划的，不能随意，从下图中也可以看出规划性。

关于apollo的生产实践另行开文，也有很多工程讲究。

下图是本文demo的passport的apollo配置，可以看到配置的工程规划：

(8).笔者容器化相关实战github

8.1.提供一个低成本容器化所有组件的最佳实践

同时维护笔者生产环境的容器化配置目录；

本文中的demo演示地址所在的个人私服就是用这个github下的yaml文件搭建的单节点K8S集群；

https://github.com/hepyu/k8s-app-config

8.2.笔者生产实践中使用/制作的jdk官方镜像

https://github.com/hepyu/oraclejdk-docker-image

8.3.本系列文章所涉及的相关资源的github备份

https://github.com/hepyu/kubernetes-microsvc-product-practice

8.4.笔者生产实践中的openresty高性能配置

https://github.com/hepyu/openrestry

(9).小结/感慨

容器化时代下的微服务看起来很美，当然实际上在生产实践中确实也很美，但是对架构师的广度和深度要求很高，要具备相当水准的后端全栈能力/思想，同时对架构师主动找活/找到有效活的能力有很高的要求，即具备自我发觉、自我完善的能力/思想。

笔者在总结的时候，碰到无数细节，在后续的系列文章中会逐步涉及所有笔者亲历的相关细节。

容器化时代下的架构师，必须是亲历一线的实践者。