架构即未来-读书笔记二

文章目录

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

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

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）
【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/coding-now/p/14660554.html