拉勾网《32个Java面试必考点》学习笔记之十二------架构演进与容器技术
本文为拉勾网《32个Java面试必考点》学习笔记.只是对视频内容进行简单整理,详细内容还请自行观看视频《32个Java面试必考点》.若本文侵犯了相关所有者的权益,请联系:[email protected]将会删除相关内容
系统架构演进
单体架构
一个项目中的多个服务混合部署在一个进程内,服务之间的交互都是通过进程内调用完成的
优点:快速开发部署服务,服务之间调用的性能最好
缺点:随着业务增长项目越来越臃肿,服务之间由于jar包引用导致频繁的依赖冲突,服务资源变更困难,一个服务可能被不同业务引用,升级资源需要多个业务方同时升级.业务方可直连业务资源,存在明显的数据安全风险.修改代码后回归困难,架构难以调整等
以上问题都是由于服务之间的强耦合所导致
微服务架构
起源是为了解决企业应用问题,特点高内聚低耦合,不同的服务单独开发单独测试单独部署,服务之间通过RPC或HTTP进行远程交互,微服务架构解决了单体架构的耦合问题,但也带来了新的问题.由于不同服务部署在不同进程或主机中,要是用前需要先找到服务,即服务发现
一般微服务采用两种发现方式
- RPC方式,通过注册中心完成服务发现.由服务调用端获得服务全部可用节点,再由client进行负载均衡调用服务
- 通过http调用服务端提供的restful接口,通过nginx反向代理完成负载均衡
不论哪种方式都从进程内通信变成了远程通信,使得性能下降,可靠性降低
分布式体统的CAP原则和BASE理论
Consistency 一致性:所有节点在同一时间的数据完全一致
Availability 可用性:任意时间总能执行读写任务
Partition tolerance 分区容差:同出现节点异常时,仍然能提供满足需求的服务
三者只可能同时满足两个
只选择CA相当于单机架构
只选择CP,则允许在极端情况下出现短时的服务不可用,如zookeeper,不适合做服务注册中心
只选择AP,则允许出现短时间不一致,如eureka
Basically Available(基本可用),Soft state(软状态),Eventually consistent(最终一致性)
是对CAP中一致性权衡的结果,即使无法做到强一致性,也可以根据系统的特点采用适当的方法得到最终一致性
云原生服务
云原生架构由微服务组成,是一种能够快速持续可靠规模化的交付业务服务的模式
一般为两种,私有云和公有云
- 容器化的微服务:云原生的主体
- Devops:对微服务的动态管理
- 持续交付:云原生的目的
IaaS提供计算资源
PaaS平台提供运行环境
微服务的解耦会导致道德业务拆分成小的服务,每个服务的部署都需要考虑单点问题,需要多机房多节点部署,会造成系统资源的浪费,服务扩容是需重新整理服务依赖的环境
容器化技术把服务的运行环境进行打包管理,解决了扩缩容时对运行环境的管理问题和服务器的利用率问题
随着容器技术的逐渐成熟,微服务架构也快速普及
云原生的12要素
- 基准代码:代码由版本管理工具管理,一个应用只有一份基准代码,运行时有多个部署实例
- 依赖:在应用中显式的声明依赖
- 配置:环境中存储配置,说明配置与代码要分开管理
- 后端服务:将依赖的后端服务当作统一资源来对待
- 构建,发布,运行:需要严格区分构建,发布,运行三个步骤,并且要按顺序进行
- 进程:以一个或多个进程运行,要保证进程的无状态性
- 端口绑定:应用启动后,相应的端口可持续提供服务直至应用关闭
- 并发:应用进程之间可以并发处理,英雌可以通过对进程方式进行水平扩展
- 易处理:应该容易被管理,可以通过优雅停机和快速启动构建最健壮的服务
- 开发/生产等价:指在开发生产环境中的应用尽可能一致
- 日志:要合理记录应用的运行日志,要把日志当作事件流来对待
- 管理进程:把后台管理任务当作一次性进程来运行
下一代架构Service Mesh
service mesh在微服务的基础上引入了sidecar边车的概念,每个服务都伴生有一个sidecar,服务的交互不再由服务自身完成,服务所有出入的请求都交由sidecar处理,在管理层面对sidecar进行统一管理,由sidecar实现服务发现,负载均衡,流量调度等
微服务与Service Mesh的区别与联系
微服务要解决的是多个服务之间的耦合问题,如上图绿色竖线,将ServiceA,B,C进行解耦,单独部署单独管理,使得每个服务都要实现服务发现,服务间远程交互,负载均衡,高可用策略,服务熔断等一系列的功能
service mesh是将与业务逻辑无关的功能进行解耦,如图中红色的线,把与服务交互的功能从服务中剥离出来,统一交由sidecar实现,让服务更聚焦于业务逻辑,提高研发效率.sidecar更专注于服务的交互与治理,追求极致的功能与性能
因此service mesh并不能称为一项新的技术,而应当是微服务的演进
由于sidecar是独立进程,所以天然适合为不同语言的服务提供统一的治理能力,因此跨语言治理也是service mesh的一个重要特点
由于引入了额外的sidecar,service mesh也产生新的性能与可靠性问题,这也是service mesh架构需要解决的问题
容器
Docker
-
作用:
- 构建,部署,运行服务
- 服务版本管理
- 屏蔽环境差异
- 隔离服务
- 提高资源利用率
-
特点:
- 开源容器技术
- 基于LXC,高效虚拟化
- 适合大规模构建
- 灵活可拓展
- 管理简单
-
概念:
- 镜像(Images
- 容器(Container
- 守护进程(Daemon
- 客户端(Client
- 镜像仓库(Repository
Docker原理
docker通过对不同运行进程进行隔离实现虚拟化
docker运用三种方式以实现进程的隔离:
- Namespace
- 进程:docker运用三种方式以实现进程的隔离利用Linux的Namespace隔离进程之间的可见性,不同的服务进程属于不同的Namespace,互相无法感知对方的存在.
- 网络:docker运用三种方式以实现进程的隔离实现了host,container,null和bridge(默认)四种网络模式.每个容器创建时都会创建一对虚拟网卡,一个在容器中一个在docker0的网桥中,组成了数据的通道.docker0的网桥通过iptables中的配置与宿主机的网卡相连,所有符合条件的请求都会通过iptables转发到docker0,再有网桥分发给相应的容器网卡.
- 挂载点(文件目录):为防止容器进程修改宿主机的文件目录,docker通过修改进程访问文件目录的根节点结合namespace来隔离不同容器进程可以访问的文件目录
- Control Groups
- UnionFS
- docker的镜像是分层结构,存在操作系统层,技术环境层,web容器层,服务代码层,层与层相互依赖通过UnionFS把Image的不同分层作为只读目录
- Container是在Image的只读目录上创建的科目可写的目录
docker有AUFS, Btrfs, overlay, Devicemapper, zfs等多种不同的存储驱动实现
Kubernetes
容器集群管理系统,不是PaaS平台
-
作用:
- 容器集群管理
- 自动化部署
- 自动扩缩容
- 应用管理
-
特点:
- 可移植
- 可扩展
- 自动化
-
概念:
- Master:管理节点,负责协调集群中所有节点的行为与活动(例,应用的运行,修改,更新等)
- Node:运行容器,可有多个Pod
- Pod:Kubernetes可创建部署的基本单位,可运行多个Container
- Container:为运行中的服务镜像,共享所属Pod的网络存储
- Service:为Pod添加标签,将其划分为不同的Service
- Deployment:表示对Kubernetes集群的一次操作(例,创建,更新,滚动升级等)
Kubernetes架构
- Master
- api server:用户资源操作的唯一入口
- 创建应用部署
- 管理部署状态
- 认证授权
- 访问控制
- api注册和发现
- 等
- controller manager:维护集群状态,包含多个controller(例,node controller,route controller,service controller)
- 故障检测
- 自动扩展
- 滚动更新
- 等
- scheduler:资源调度
- api server:用户资源操作的唯一入口
- etcd:保存集群状态
- kubectl:运行命令的管理工具,与Master中的api server进行交互,通过api server下达指令
- Node
- 容器运行时(container runtime):可以不是docker
- Pod:可看作虚拟服务器,可运行多个Container
- kubelet:负责人与Master通信,周期性访问api server,进行检查和报告,执行容器的操作,维护容器的生命周期,也负责volume和网络的管理
- kube-proxy:处理网络代理和容器的负载均衡,通过改变iptables规则,控制容器上的tcp和udp包
- 容器运行时(container runtime):可以不是docker
Kubernetes把所有被管理的资源看作对象,使得对资源的管理变成对对象属性的设置,配置文件使用yaml格式
对象可大致分为四类:
- 资源对象
- 配置对象
- 存储对象
- 策略对象
考察点
- 表达沟通
- 分布式架构的理解
- 系统可用性,扩展性
- 故障的应对方法
- 熔断,容灾,流量迁移
- 架构设计中的解耦
- 了解系统优化的常用方法
- 并行,异步,水平扩展,垂直扩展,预处理,缓存,分区
- 对工作的熟悉程度
- 自己项目的规模,调用量级
- 解决问题能力
加分项
- 关注业界最新趋势
- 能提供方案对比选型
面试技巧
- 交代背景:
- STAR法则(情境(situation)、任务(task)、行动(action)、结果(result))
- 描述架构:架构图或交互流程图
- 做了什么:突出重点
- 结果如何:用实力作证
- 注意量化相关性能数据
- 如何改进:存在的问题与解决方法
提示
- 提前思考,提前准备
- 项目在精不在多
- 我了解的,就是我的
- 体现对架构的理解,对设计的理解