目录

• 1、微服务简介
• 2、K8s部署微服务考虑的问题
• 3、项目迁移到k8s流程

1、微服务简介

微服务优点

• 服务组件化

  每个服务独立开发、部署，有效避免一个服务的修改引起整个系统重新部署

• 技术栈灵活

  约定通信方式，是得服务本身功能实现对技术要求不再那么铭感

• 独立部署

  每个微服务独立部署，加快部署速度，方便扩展

• 扩展性强

  每个微服务可以部署多个，并且有负载均衡能力

• 独立数据

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

微服务缺点

• 沟通成本
• 数据一致性
• 运维成本
• 内部架构复杂性

微服务和单体应用

单体应用，易于部署、测试，但是会使得代码膨胀，难以维护，构建和部署成本大，新人上手难

适用于微服务的框架：Spring Boots、Spring Cloud、Dubbo

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

微服务架构图

微服务流程图

• 微服务间如何通信？

  REST API、RPC、MQ

• 微服务如何发现彼此？

  通过注册中心进行注册，发现

• 组件之间怎么个调用关系？

  微服务内部处理逻辑

• 那个服务作为整个网站入口？

  网关，即gateway

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

  只需要网关入口对外即可

• 微服务怎么部署？更新？扩容？

  基于Kubernetes就可以轻易实现

• 区分有状态应用和无状态应用？

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

  有状态应用：有固定存储，例如：mysql、mongodb

有状态应用不建议部署到kubernetes

为什么要用注册中心

微服务太多面临的问题：

• 怎么记录一个微服务多个副本接口地址？

• 怎么实现一个微服务多个副本负载均衡？

• 怎么判断一个微服务副本是否可用？

  主流注册中心：Eureka，Nacos

不同环境如何区分配置文件

• configmap
• entrypoint.sh
• java -jar --spring.profiles.active=dev xxx.jar
• 统一配置中心，例如：Apollo，Disconf

3、项目迁移到k8s流程

1. 制作镜像（应用程序、运行环境、文件系统）

2. 控制器管理Pod

   Deployment：无状态部署

   StatefulSet：有状态部署

   DaemonSet：守护进程部署

   Job & CronJob：批处理

3. 暴露应用

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

   Service引入为了解决Pod的动态变化，提供服务发现和负载均衡

   支持Cluster IP，NodePort以及LocalBalancer三种类型

   Service的底层实现主要实现有iptables和ipvs两种网络模式

   使用CoreDNS解析Service名称

   通过Label关联Pod

4. 对外发布应用（ingress）

   通过Service关联Pod

   基于域名访问

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

5. 日志/监控

   容器部署过程中一般有以下三种数据：

   启动时需要初始化数据，可以是配置文件。

   启动过程中产生的临时数据，该临时数据需要多个容器共享

   启动过程中产生的持久化数据

   主流方案：FileBeat + ELK、Prometheus + Grafana