从运维角度看微服务架构

一、引言

微服务架构是一项在云中部署应用和服务的新技术。

1.1、微服务是什么？

微服务是一种软件设计风格，开发人员在开发项目时，是一种微服务这种标准去设计的，这种的设计风格是一种将单体的应用，拆分为多个小的组件去开发，那每个组件是独立的部署，独立的测试，服务之间采用轻量级的通信。

1.2、微服务的特点

• 服务的组件化

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

• 技术栈灵活

约定通信方式，使得服务本身功能实现对技术要求不再那么敏感，可以根据不停语言进行开发。

• 独立部署

每个微服务独立部署，加快部署速度，方便扩展，比起单体应用来讲要小，轻量级的，方便快速部署，扩展。

• 扩展性强

每个微服务可以部署多个，没有多少依赖，并且有负载均衡能力，比如一个服务部署一个副本或5个副本，通过k8s可以更好的去扩展我们的应用。

• 独立数据

每个微服务有独立的基本组件，例如数据库、缓存等，可能有不同的开放人员，不依赖。

1.3、微服务不足

• 沟通成本：由于组件都是分开来开发的，不同的项目组，沟通起来不方便，单体应用就是集中起来开发的。

• 数据一致性：保证这个数据，独立的组件数据是一致性。

• 运维成本：虚拟机部署，需要考虑组件性，调用关系，监控，配置。

• 内部架构复杂性：分布式的，需要轻量级的通信，rbac,MQ,还有很多的数据库。

1.4、单体应用 vs 微服务

单体架构优势：	单体架构不足：
易于部署	代码膨胀，难以维护
易于测试	构建、部署成本大、新人上手难

mark

单体应用：适合于轻量级的应用，不提供复杂的应用。

微服务适合：比较大的应用，复杂一些的。

mark

1.5、java微服务框架

spring Boot 是独立的。

spring cloud ,基于spring boot的。

Dubbo 阿里巴巴的开源微服务框架，通过rbc实现组件之间的通信。

微服务架构图：

mark

为什么要用注册中心？（主流注册中心： Eureka， Nacos）

• 1、需要记录一个或者多个微服务多个副本接口地址；
• 2、需要实现一个或者多个微服务多个副本负载均衡；
• 3、需要判断一个或者多个微服务的副本是否可用；

mark

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

第一种：java-jar --spring.profile.active=dev xxx.jar

第二种：统一的配置中心，例如携程的Apollo，百度的Disconf,动态根据不同的环境进行配置，页面进行管理，需要二次开发。

1.6、项目迁移到k8s平台是怎样的流程

举个例子了解一下大概的一个怎样的流程：

1制作镜像 --> 2控制管理pod --> 3暴露应用 --> 4对外发布应用 --> 5日志/监控

控制器管理Pod：

deployment :无状态部署

statefulset ：有状态部署

Daemonset :守护进程部署

job & cronjob：批处理

暴露应用Service

service定义pod的逻辑集合，提供服务发现及负载均衡

支持cluster ip， nodeport， loadbalancer三种类型

底层实现iptables/ipvs两种网络模式

通过label关联pod

使用Coredns解析service名称

mark

ingress

通过service关联pod

基于域名访问

通过ingress controller实现pod的负载均衡

支持tcp、udp 4层和http7层

mark

pod数据持久化

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

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

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

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

mark