拉勾网《32个Java面试必考点》学习笔记之十二------架构演进与容器技术

本文为拉勾网《32个Java面试必考点》学习笔记.只是对视频内容进行简单整理,详细内容还请自行观看视频《32个Java面试必考点》.若本文侵犯了相关所有者的权益,请联系:txzw@live.cn.将会删除相关内容

系统架构演进

---

单体架构

一个项目中的多个服务混合部署在一个进程内,服务之间的交互都是通过进程内调用完成的
优点:快速开发部署服务,服务之间调用的性能最好
缺点:随着业务增长项目越来越臃肿,服务之间由于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要素

1. 基准代码:代码由版本管理工具管理,一个应用只有一份基准代码,运行时有多个部署实例
2. 依赖:在应用中显式的声明依赖
3. 配置:环境中存储配置,说明配置与代码要分开管理
4. 后端服务:将依赖的后端服务当作统一资源来对待
5. 构建,发布,运行:需要严格区分构建,发布,运行三个步骤,并且要按顺序进行
6. 进程:以一个或多个进程运行,要保证进程的无状态性
7. 端口绑定:应用启动后,相应的端口可持续提供服务直至应用关闭
8. 并发:应用进程之间可以并发处理,英雌可以通过对进程方式进行水平扩展
9. 易处理:应该容易被管理,可以通过优雅停机和快速启动构建最健壮的服务
10. 开发/生产等价:指在开发生产环境中的应用尽可能一致
11. 日志:要合理记录应用的运行日志,要把日志当作事件流来对待
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运用三种方式以实现进程的隔离:

1. Namespace
   • 进程:docker运用三种方式以实现进程的隔离利用Linux的Namespace隔离进程之间的可见性,不同的服务进程属于不同的Namespace,互相无法感知对方的存在.
   • 网络:docker运用三种方式以实现进程的隔离实现了host,container,null和bridge(默认)四种网络模式.每个容器创建时都会创建一对虚拟网卡,一个在容器中一个在docker0的网桥中,组成了数据的通道.docker0的网桥通过iptables中的配置与宿主机的网卡相连,所有符合条件的请求都会通过iptables转发到docker0,再有网桥分发给相应的容器网卡.
   • 挂载点(文件目录):为防止容器进程修改宿主机的文件目录,docker通过修改进程访问文件目录的根节点结合namespace来隔离不同容器进程可以访问的文件目录
2. Control Groups
3. 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:资源调度
• etcd:保存集群状态
• kubectl:运行命令的管理工具,与Master中的api server进行交互,通过api server下达指令
• Node
  • 容器运行时(container runtime):可以不是docker
    • Pod:可看作虚拟服务器,可运行多个Container
  • kubelet:负责人与Master通信,周期性访问api server,进行检查和报告,执行容器的操作,维护容器的生命周期,也负责volume和网络的管理
  • kube-proxy:处理网络代理和容器的负载均衡,通过改变iptables规则,控制容器上的tcp和udp包

Kubernetes把所有被管理的资源看作对象,使得对资源的管理变成对对象属性的设置,配置文件使用yaml格式
对象可大致分为四类:

1. 资源对象
2. 配置对象
3. 存储对象
4. 策略对象

考察点

• 表达沟通
• 分布式架构的理解
  • 系统可用性,扩展性
  • 故障的应对方法
    • 熔断,容灾,流量迁移
  • 架构设计中的解耦
• 了解系统优化的常用方法
  • 并行,异步,水平扩展,垂直扩展,预处理,缓存,分区
• 对工作的熟悉程度
  • 自己项目的规模,调用量级
• 解决问题能力

加分项

• 关注业界最新趋势
• 能提供方案对比选型

面试技巧

• 交代背景:
  • STAR法则(情境(situation)、任务(task)、行动(action)、结果(result))
• 描述架构:架构图或交互流程图
• 做了什么:突出重点
• 结果如何:用实力作证
  • 注意量化相关性能数据
• 如何改进:存在的问题与解决方法

提示

• 提前思考,提前准备
• 项目在精不在多
• 我了解的,就是我的
• 体现对架构的理解,对设计的理解