读<架构即未来>,记录个人收获

读书第二阶段应理论结合实际,从组织,过程、架构三个方面任选一到二个,结合行业和我司实践,试请剖析:

1、理论到实践中的差距在哪里?

项目研发过程中, 项目范围、项目时间和项目成本是相互制约的,项目的质量是这三个因素的综合结果。

针对快速变化的市场环境,产品应快速响应,快速迭代,多版本,多频次发布上线,采用敏捷研发过程-SCRUM机制是一种提高产出效率的方式。

理论上,掌握SCRUM研发过程,团队成员需要有一个熟悉、磨合的过程。

SCRUM实践过程中需要有一定的仪式感,培养团队的敏捷习惯,SCRUM Master需要掌握相关的技能,敏捷过程贯穿需求输入、产品设计、开发、测试、线上运营全生命周期,是不断迭代循环上升的过程。

每一个Sprint周期,从需求输入阶段就需要明确项目范围,需要有相关自动化工具的支持以提升工作效率,相对于传统的瀑布研发模式,敏捷过程轻文档,重沟通,关键过程需要输出文档。

在一个迭代周期内需求相对稳定,各个迭代版本之间的项目范围需要提前规划,总之,实践中面对的挑战如下:

  • 项目范围,功能优先级等的划分对需求分析人员是一个挑战,也可以采用2/8法则来辅助确定功能优先级。
  • sprint迭代过程中,开发人员对story的粒度、story point的预估都是很主观的,要达到团队认知基本一致,需要耗费一定的时间,开发人员需要转变思维模式,主动思考,需要学习敏捷理念,积极参与全流程,不要局限自己。
  • 架构设计的可扩展性也是一个考验,既要满足当前版本功能,又能支持以后sprint的功能迭代,需要有一定前瞻性,项目关键特性必须满足的情况下,要考虑可能的扩展方案,虽不需要马上实施,但是未来实施时应该能很容易支持,而不需要改动现有功能。
  • 由于发布变更频繁,需要引入各种自动化过程工具以减少人工操作的失误,解放双手,运维人员的相关技能也需要提升、需要引进各种提高工作效率的工具。
  • 另外,兼容性问题 也是必须要考虑的,各个sprint版本的代码、数据兼容性对开发人员,架构设计都是一个挑战。

2、如何对理论目标做平衡与取舍,如复杂性和有效性的取舍,质量和效率的取舍等。

在时间成本,人力成本,硬件成本的各种约束条件下,项目的成功落地应用并实现业务价值,项目才算是成功的。不同阶段,不同的项目,上线运行期关注的重点是不一样的,各项指标的重要性也是不同的,所以在研发阶段就要具体问题具体分析,要获取最大化收益,需要有取舍,有功能优先级意识,从需求源头把控引导,20/80现象大量存在,很复杂的功能不一定是很有效的,也不一定是用户最常用的。

  • 业务复杂性方面,需要梳理主干,功能分解,有效性需要根据历史数据分析、预估,可以通过逐步迭代的方式,完善细化。通过技术手段包括用户行为分析,日志分析,监控等量化指标来分析、确定实施效果。

  • 技术复杂性方面,需要提升整体技术水平,关注效率提升,跟进业界先进技术,具体项目层面需重点关注系统核心功能的稳定性,可用性,安全性,扩展性。

  • 质量和效率是一对矛盾体,不能选其一而走向极端,必然是追求两者的相对平衡,根据项目的重要性不同,质量的标准也可以分级,同时做好基础性的保障工作,避免项目的不可用。-

    • 追求质量,必然设置各种规则制度、约束研发过程,成本巨大,效率低下,不能快速响应多变的外部环境。仅追求效率,质量没保障,则很容易短视,埋下隐患,留下技术债务,不利于长期的可持续发展。
    • 追求效率的前提,必须保证基本的质量约束,没有质量保证的产品,产生不了大的业务价值,效率也就没有意义,质量保障部门可以通过软件来自动化监控、量化影响质量的过程因素,辅助改善研发过程。
    • 通过加强业务知识学习、学习新技术、采用自动化工具等提升研发过程中的工作效率、 部分实现效率提升的同时不降低项目质量。核心的功能,必须要重点关注质量属性,设计实现上要考虑全面,各种场景都要考虑,这种情况效率降低是值得的

3、AFK在架构设计中如何应用,试剖析Flink或者K8S架构

AKF立方体简述

在这里插入图片描述
X轴 -水平扩展,服务资源的复制、系统负载的均分,提升稳定性,可用性的最常规做法。
Y轴 -领域功能拆分,每个领域独立部署,独立演化,研发效率提高,服务拆分粒度是个考验,避免走向极端,不拆分即单体应用,拆分过细则服务间交互复杂,稳定性弱,运维成本高,需要权衡做折中处理。
Z轴 - 数据分区,多数据中心,多集群联邦机制等都是Z轴扩展的体现方式。
一般来说,x,y轴扩展结合起来完成服务的稳定性,可用性建设,x,y轴正交,互不影响,z轴的扩展成本比较高。

Flink架构介绍

在这里插入图片描述
Flink作为新兴起的计算框架,想要统一流、批计算场景,国内发展迅速,Flink把批计算看作是有界数据流的流计算来处理。

  • 从进程层面来说 Flink框架主要由JobManager,TaskManager两个进程组成。

  • JobManager 作为Flink框架的控制中心,由三个组件组成:

    • ResourceManager 资源管理器,管理 task slots,支持YARN, Mesos, Kubernetes and standalone deployments等计算环境。
    • Dispatcher 负责job提交,为每个job启动新的JobMaster,另外提供集群管理控制台UI查看集群运行情况。
    • JobMaster 一个job执行流程的总管家,不同job启动不同的JobMaster,支持不同的job类型,一个job也就是一个数据处理流程,相当于工作流模型中的process概念,不同job可以并行在Flink集群上执行,互不影响。
    • JobManager是计算任务调度控制中心,不能单点故障,官方介绍的HA配置方案是建立JobManager集群,采用zk选主节点,其他节点做stand by节点。
    • 总之,JobManager 服务作为独立进程,是AKF立方体扩展的Y轴扩展。X轴扩展是部署多个实例,避免单点故障,配合zk进行选主来实现高可用,是X,Y轴扩展性的结合。
  • TaskManager

    • worker节点,slot均分memory, 目前版本不分cpu资源。
    • worker节点负责具体task的执行,涉及资源的使用策略,不同场景有不同配置,同一个job/process的不同task可以共用同一个jvm,也可以资源隔离。
    • TaskManager 独立的执行节点,Flink集群至少有一个,可以水平扩展,X轴扩展即可
  • Flink Code
    Flink程序的客户端代码,产生Taskflow的处理逻辑定义,确定执行环境等,支持三种场景

    • Flink Session Cluster 长时间执行的,资源隔离性差,job周期和 session周期不一致。
    • Flink Job Cluster 生命周期和Job执行周期一致,job结束,job cluster进程退出。
    • Flink Application Cluster job提交由ApplicationClusterEntryPoint调用jar里的main方法启动,不需要client,隔离性好。
    • Flink Code 数据处理流程定义,面向开发者,应支持多语言,多执行场景如上三种,作用Flink集群的一个客户端,不需要考虑X,Y扩展性。

yarn架构浅析

在这里插入图片描述
和Flink架构比较组件很相似,Y轴-按职能拆分

  • client 调度任务定义,支持各种任务的定义,多种提交方式,不需要X方向扩展。属于Y轴扩展的一种。
  • ResourceManager
    • scheduler 获取资源,任务调度
    • ApplicationsManager 任务提交,失败处理,心跳检测
    • 调度平台核心,高可用方案
    • 支持YARN联邦机制- Z轴 按数据权限,用户组拆分
  • NodeManager
    • ApplicationMaster 相互独立,支持不同的任务类型,
    • Node 任务执行节点
    • Node节点很容易X方向 水平扩展

k8s架构浅析

深入剖析K8s
控制节点,即 Master 节点,由三个紧密协作的独立组件组合而成,分别是

  • 负责 API 服务的 kube-apiserver、
  • 负责调度的 kube-scheduler,
  • 负责容器编排的 kube-controller-manager。
  • 整个集群的持久化数据,则由 kube-apiserver 处理后保存在 Etcd 中。

计算节点 Node,kubelet 主要负责同容器运行时(比如 Docker 项目)打交道。
这个交互所依赖的,是一个称作

  • CRI(Container Runtime Interface)的远程调用接口,这个接口定义了容器运行时的各项核心操作,比如:启动一个容器需要的所有参数。这也是为何,Kubernetes 项目并不关心你部署的是什么容器运行时、使用的什么技术实现,只要你的这个容器运行时能够运行标准的容器镜像,它就可以通过实现 CRI 接入到 Kubernetes 项目当中。而具体的容器运行时,比如 Docker 项目,则一般通过 OCI 这个容器运行时规范同底层的 Linux 操作系统进行交互,即:把 CRI 请求翻译成对 Linux 操作系统的调用(操作 Linux Namespace 和 Cgroups 等)。
  • kubelet 还通过 gRPC 协议同一个叫作 Device Plugin 的插件进行交互。这个插件,是 Kubernetes 项目用来管理 GPU 等宿主机物理设备的主要组件,也是基于 Kubernetes 项目进行机器学习训练、高性能作业支持等工作必须关注的功能。
  • kubelet 的另一个重要功能,则是调用网络插件和存储插件为容器配置网络和持久化存储。
  • 这两个插件与 kubelet 进行交互的接口,分别是
  • CNI(Container Networking Interface)和 CSI(Container Storage Interface)
Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐