亲宝软件园·资讯

展开

微服务交付至kubernetes流程

jasonminghao 人气:0
[TOC] #1、微服务简介 **微服务优点** * 服务组件化 每个服务独立开发、部署,有效避免一个服务的修改引起整个系统重新部署 * 技术栈灵活 约定通信方式,是得服务本身功能实现对技术要求不再那么铭感 * 独立部署 每个微服务独立部署,加快部署速度,方便扩展 * 扩展性强 每个微服务可以部署多个,并且有负载均衡能力 * 独立数据 每个微服务有独立的基本组件,例如数据库、缓存等 **微服务缺点** * 沟通成本 * 数据一致性 * 运维成本 * 内部架构复杂性 **微服务和单体应用** 单体应用,易于部署、测试,但是会使得代码膨胀,难以维护,构建和部署成本大,新人上手难 适用于微服务的框架:Spring Boots、Spring Cloud、Dubbo #2、K8s部署微服务考虑的问题 **微服务架构图** ![](https://img2020.cnblogs.com/blog/1679739/202004/1679739-20200402070638566-968510048.png) [微服务流程图](https://www.processon.com/view/5b179d12e4b06350d454c168?fromnew=1) * 微服务间如何通信? 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

加载全部内容

相关教程
猜你喜欢
用户评论