微服务交付至kubernetes流程

⽬录

1、微服务简介

微服务优点

服务组件化

每个服务独⽴开发、部署，有效避免⼀个服务的修改引起整个系统重新部署技术栈灵活

约定通信⽅式，是得服务本⾝功能实现对技术要求不再那么铭感独⽴部署

每个微服务独⽴部署，加快部署速度，⽅便扩展扩展性强

每个微服务可以部署多个，并且有负载均衡能⼒独⽴数据

每个微服务有独⽴的基本组件，例如数据库、缓存等微服务缺点

沟通成本数据⼀致性运维成本

内部架构复杂性

微服务和单体应⽤

单体应⽤，易于部署、测试，但是会使得代码膨胀，难以维护，构建和部署成本⼤，新⼈上⼿难适⽤于微服务的框架：Spring Boots、Spring Cloud、Dubbo、Go-micro .....

2、K8s部署微服务考虑的问题

微服务架构图

微服务间如何通信？

REST API、RPC、MQ（后两者主流）。微服务如何发现彼此？

通过注册中⼼进⾏服务的注册与发现。组件之间怎么个调⽤关系？微服务内部处理逻辑。

那个服务作为整个⽹站⼊⼝？

⽹关，即gateway（也是单独的⼀个微服务）。

那些微服务需要对外访问？

只需要⽹关gateway⼊⼝对外即可，

⼀般都是先为gateway创建svc，然后由Ingress指定到该svc。微服务怎么部署？更新？扩容？基于Kubernetes就可以轻易实现，Kubernetes⽣来就是为了这些。

如何区分有状态应⽤和⽆状态应⽤？

⽆状态应⽤：不考虑存储，不维护有状态信息，也不考虑和其它服务副本是否有关系。

有状态应⽤：有固定存储，维护集群状态信息，例如：mysql、mongodb，有状态应⽤不建议部署到kubernetes。为什么要⽤注册中⼼？微服务太多⾯临的问题：

怎么记录⼀个微服务多个副本接⼝地址？怎么实现⼀个微服务多个副本负载均衡？怎么判断⼀个微服务副本是否可⽤？

主流注册中⼼：Eureka，Nacos，Etcd；

注册中⼼可基于statefulset部署到k8s集群中，也可以部署在集群外。不同环境如何区分配置⽂件？

configmap：通过不同的环境去挂载不同的配置⽂件entrypoint.sh：通过启动脚本区分

java -jar --spring.profiles.active=dev xxx.jar：基于启动命令区分统⼀配置中⼼，例如：Apollo，Disconf

3、项⽬迁移到k8s流程

1. 制作镜像（应⽤程序、运⾏环境、⽂件系统）基础镜像：Debian 或 应⽤程序的运⾏环境镜像应⽤程序：Go，Java，Python ....

运⾏环境：不同的语⾔都需要有特定的运⾏环境（例如java需要jdk）⽂件系统：忽略2. 控制器管理Pod

Deployment：⽆状态部署

StatefulSet：有状态部署（MySQL、Mongodb、Redis ...）DaemonSet：守护进程部署Job & CronJob：批处理

3. 暴露应⽤

Service定义了Pod的逻辑集合和访问这个集合的策略，

Service引⼊为了解决Pod的动态变化，提供服务发现和负载均衡，⽀持Cluster IP，NodePort以及LocalBalancer三种类型，

Service的底层实现主要实现有iptables和ipvs两种⽹络模式，推荐ipvs，使⽤CoreDNS解析Service名称，通过Label关联Pod。

4. 对外发布应⽤（ingress）通过Service关联Pod，基于域名访问，

通过Ingress Controller实现Pod的负载均衡（⽀持TCP/UDP 4层和HTTP 7层）。

最后在Ingress前⾯部署外⽹⽤户统⼀⼊⼝实现七层代理/四层转发（Nginx、HaProxy...）

5. ⽇志采集

Pod在运⾏的时候会产⽣应⽤⽇志，需要将其⽇志⽂件信息采集到统⼀的数据库中存储，然后从⼀个平台中展⽰易给开发查阅⽇志信息和错误⽇志信息，易于排查问题主流⽅案：FileBeat + ELK（⾼性能和解耦：+kafka）6. 监控

不管是k8s集群Master还是Node，以及Pod，我们需要知道它们运⾏的具体状况，占⽤多少资源，剩余多少资源，就得通过监控的⽅式去实现。主流⽅案：Prometheus + Grafana + ...Export