从零开始学架构笔记

Posted 2023-04-05 万能菜道人

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了从零开始学架构笔记相关的知识，希望对你有一定的参考价值。

概念

   模块和组件
       从逻辑的角度来拆分后得到的单元就是“模块”，从物理的角度来拆分系统得到的单元就是“组件”；
划分模块的主要目的是职责分离，划分组件的主要目的是单元复用。
       从不同的角度拆分系统而已
   架构的含义
       首先，“系统由一群关联个体组成”，这些“个体”可以是“子系统”“模块”“组件”等，架构需要明确系统包含哪些“个体”
       其次，系统中的个体需要“根据某种规则”运作，架构需要明确个体运作和协作的规则
       第三维基百科的定义中用到了“基结构”这个说法，我改为 “顶层结构”，可更好区分系统子系统，避免将系统架构和子系统架构混淆导致架构层次混
   架构应有的作用
       高性能、高可用、高扩展
   目的！！！
       是为了解决复杂度带来的问题
       一些重要的设计一定是和系统中复杂度较高的部分有关
       如：Docker 不是万能的，只是为了解决资源重用和动态分配而设计的，如果我们的系
统复杂度根本不是在这方面，那么引入 Docker 没有什么意义。
   复杂度的来源
       高性能
           软件系统中高性能带来的复杂度主要体现在两方面，方面是单台计算机内部为了高性能
带来的复杂度：另方面是多台计算机集群为了高性能带来的复杂度。
           单机复杂度
               操作系统提供了线程进程、进程间通信的概念
               还有互斥锁
               需要考虑如下技术点：多进程、多线程、进程间通信、多线程并发等
           集群的复杂度
               需要增加一个任务分配器
               多个任务分配器多对多
                   更加复杂
               太多任务和机器性能不会提升了
                   只能任务分离
                   关键的就是要把握分解的粒度
       高可用
           这里的高可用并不是代码高可用，而是冗余，安全性
       可拓展性
           第一种常见的方案
               预测变化
                   不能每个设计点都考虑可扩展性
                   不能完全不考虑可扩展性
                   所有的预测都存在出错的可能性
               应对变化
                   要划分合适的稳定层和变化层）系统需要拆分出变化层和稳定层。
                   ）需要设计变化层和稳定层之间的接口。
           第二种方案
               提炼出一个“抽象层”和一个实现层”
       低成本
           小型的就不需要考虑了
           一般都是引入新技术，或者创造新技术
       安全
           功能安全是“防小偷”
           而架构安全就是“防强盗”
       规模
           功能越来越多，导致系统复杂度指数级上升
           数据越来越多，系统复杂度发生质变

架构i设计原则与流程

   原则
       演化原则
           演化优于一步到位
               软件架构要根据业务发展不断变化
               时刻提醒自己不要贪大求全，或者盲目照搬
大公司的做法，而是应该认真分析当前务的特点，明确业务面临的主要题，设计合理的架
构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构
       简单原则
           简单优于复杂
               软件领域不同于其他，复杂代表着问题
                   ？根本原因在于电路
旦设计好后进入生产，就不会再变，复杂性只是在设计时带来影响；而个软件系统在投入使
用后，后续还有源源不断的需求要实现，因此要不断地修改系统，复杂性在整个系统生命周期
直都有很大影响。
               复杂性
                   结构的复杂性
                       组件越多，就越有可能其中某个组件出现故障，从而导致系统故障
                       某个组件改动，会影响关联的所有组件，这些被影
响的组件同样会继续递归影响更多的组件
                       定位一个复杂系统中的问题总是比简单系统更加困
难
                   逻辑复杂性
                       结构简单，一个组件也不行，逻辑太复杂了，要取舍
       合适原则
           合适优于业界领先
               将军难打无兵之仗。
                   没那么多人，却想干那么多活，是失败的第一个主要原因
               罗马不是一天建成的。
                   没有那么多积累，却想一步登天，是失败的第二个主要原因
               冰山下面才是关键
                   没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因
               真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够
合理地将资源整合在一井发挥出最大功效，井且能够快速落地。这也是很 AT （百度，阿
里巴、腾讯）出来的架构到了公司或创业团队反而做不出成绩的原因，因为没有了大公
司的平台、资源、积累，只是生搬硬套大公司的做法，必然会失败。
   流程
       1.识到复杂度
           只有正确分析出了系统的复杂性，后续的架构设计方案才不会偏离方向
           架构的复杂度主要来源于“高性能”“高可用”“可扩展”等个方面，但架构师在具体判
断复杂性的时候，不能生搬硬套，认为任何时候都从这三个方面进行复杂度分析就可以了。实
际上绝大部分场景下，复杂度只是其中的某个，少数情况下包含其中两个，如果真的出现
需要解决三个或个以上的复杂度，要么说明这个系统之前做得实在是太烂了，要么架构
的判断出现了严重失误
       2.设计备选方案
           例如可用的主备方案、集群方案，高性能的负载均衡、多路复
用，可扩展的分层、插件化等技术，绝大部分时候我有了明确的目标后，按图索骥就能够找
到可选的解决方案。
           备选方案的数量以 3-5个为最佳。
           备选方案的差异要比较明显。
           备选方案的技术不要只局限于己经熟悉的技术
           常见错误
               设计最优秀的方案！
               ：只做一个方案！
               备选方案过于详细
                   耗费了大量的时间和精力
                   将注意力集中到细节中，忽略了整体的技术设计，导致备选方案数不够或差异不大；
                   备选阶段关注的是技术选型，而不是技术细节
       3.评估和选择备选万案
           最简派
           最牛派
           最熟派
           领导派
           360 度环评”
               常见的方案质属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩
展性等。在评估这些质属性时，需要遵循架构设计原则 “合适原则”和原则 “简单原则”，
避免贪大求全，基本上某个质属性能够满足定时期内业务发展就可以了
           例子
               先理出来各方面哪个更加优秀
               然后按照第一优先级，第二优先级来选择
       4.详细方案设计
           将技术上的细节设计清楚
           可能会出现想象遗漏，细节过于庞大

高性能架构模式

   存储高性能
       关系数据库
           读写分离
           分库分表
       这里的细节我跳过了
   计算高性能
       IO模型
           阻塞，非阻塞，同步，非同步
       进程模型
           单进程，多进程，多线程
       具体一些方案
           PPC
               fork ... close 子进程方式
               优点、
                   实现简单
               缺点
                   fork 代价高
                   父子进程通信复杂
                   数量多的话性能消耗严重
           prefork
               提前创建好子进程，延时会好很多
           TPC
               新建线程来处理
               优点
                   fork 代价低
                   父子进程通信简单
               缺点
                   死锁问题
                   可能互相影响，导致进程崩溃
           prethread
               减少TPC的延时
           Reactor(Dispatcher 模式)
               即 IO多路复用统一监昕事件，收到事件后分配（ Dispatch ）给某个进程。
           Proactor
               Reactor 塞同步网络模型
   集群高性能
       先跳过

高可用架构模式

   CAP定理
       在一个分布式系统指互相连接并共数据的节点的合）中，当涉及
操作时，只能保证致性（ Consistence ）、可用性（ Availabilit ）、分区容错性（ Part ition Tolerance)
者中的两个，另外一个必须被牺牲
   FMFA
       故障模式与影响分析”
       FMEA 是一种在各行各业都有广泛应用的可用性分析方法，
通过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确定失效对于系统
的最终影响
       具体分析方法
           给出初始的架构设计图
           假设架构中某个部件发生故障。
           ）分析此故障对系统功能造成的影响
           根据分析结果，判断架构是否需要进行优化
   跳过
       存储高可用
           主从复制
       计算高可用
       业务高可用

可拓展模式

   基本思想都可以总结为个字拆！
   常见的拆分思路
       面向流程拆分
           将整个业务流程拆分为几个阶段，每个阶段作为部分。
       面向服务拆分
           将系统提供的服务拆分，每个服务作为一部分。
       面向功能拆分
           将系统提供的功能拆分，每个功能作为部分
       要深刻理解流程，服务和功能
           例子
               简单的学生信息管理系统为例
                   面向流程拆分
                       展示层→业务层→数据层→存储层，
                       展示层负责用户页面设计，不同业务有不同的页面例如，登录页面、注册页面、
信息管理页面、安全设置页面等。
业务层负责具体业务逻辑的处理。例如，登录、注册、信息管理修改密码等业务
数据层完成数据访问例如，增删改查数据库中的数据，记录事件到日志文
件等
存储层负责数据的存储例如，关系型数据库 mysql 、缓存系统 Memcache
                   面向服务拆分
                       将系统拆分为注册、登录、信息管理安全设置等服务
                   面向功能拆分
                       每个服务都可以拆分为更多细粒度的功能，例如：
注册服务提供多种方式进行注册，包括手机号注册、身份证注册、学生邮箱注册三
个功能
登录服务包括手号登录、身份证登录、邮箱登录三个功能。
信息管理服务包括基本信息管理、课程信息管理、成绩信息管理等功能。
安全设置服务包括修改密码、安全于机、找回密码等功能。
   可拓展方式
       拆分能够减少出错导致的问题范围
       不同拆分方式的优点
           面向流程
               扩展时大部分情况只需要修改某一层，少部分情况可能修改关联的两层，不会出现所有
层都同时要修改。例如，学生信息管理系统，如果我们将存储层从 MySQL 扩展为同时
支持 MySQL Oracle ，那么只需要扩展存储层和数据层即可，展示层和业务层无须变
动。
           面向服务拆分
               对某个服务扩展，或者要增加新的服务时，只需要扩展相关服务即可，无须修改所有的
服务。同样以学生管理系统为例，如果我需要在注册服务中增加一种“学号注册”功
能，则只需要修改 “注册服务”和“登录服务”即可，“信息管理服务 ”和“ 安全设置
服务无须修改。
           面向功能拆分
               对某个功能扩展，或者要增加新的功能时，只需要扩展相关功能即可，无须修改所有的
服务。同样以学生管理系统为例，如果我增加“学号注册”功能，则只需要在系统中
个新的功能模块，同时修改“登录功能”模块即可，其他功能都不受影响
       不同拆分方式导致不同的架构
           面向流程
               分层架构
           面向服务
               SOA，微服务。
           面向功能
               微内核架构。
   分层架构
       常见的
           N=2
               C/S 架构、 B/S架构
           N=3
               MVC 架构、 MVP 架构
       详解
           要分的清楚，不会有模棱两可的模块，即每个中的组件只处理本的逻辑
           保证依赖是稳定的，复杂的操作系统接口甚至都需要一层
           要层层递进，不能跳
               ，分层架构的优势就体现在通过分层强制约束两两依赖，旦自由选
               择绕过分层，时间一长，架构就会变得混乱。
   SOA架构
       三个概念
           服务
               所有业务功能都是项服务，服务就意味着要对外提供开放的能力，当其他系统需要使
用这项功能时，无须定制化开发。
           ESB
               ，中文翻译为“企业服务总线”。从名字就可以看出
ESB 参考了计算机总线的概念计算机中的总线将各个不同的设备连接在起， ESB
将企业中各个不同的服务连接在一起
           松糯合
               松辑合的目的是减少各个服务间的依赖和互相影响因为采用 SOA 架构后，各个服务是相
互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖。如果做不到松祸合，
某个服务一升级，依赖它的其他服务全部故障，这样肯定是无法满足业务需求的。
       优缺点
           SOA 解决了传统 IT 系统重复建设和扩展效率低的问题，但其本身也引入了更多的复杂性
SOA 最广为人垢病的就是 ESB, ESB 需要实现与各种系统间的协议转换、数据转换、透明的动
态路由等功能
   微服务
       对比
           SOA
               SOA 更加适合于庞大、复杂、异构的企业级系统，这也是 SOA 诞生的背景这类系统
的典型特征就是很多系统已经发展多年，采用不同的企业级技术，有的是内部开发的，
有的是外部购买的，无法完全推倒重来或进行大规模的优化和重构。因为成本和影响太
大，只能采用兼容的方式进行处理，而承担兼容任务的就是 ESB
           微服务
               微服务更加适合于快速、轻量级、基于 We 的互联网系统，这类系统业务变化快，需
要快速尝试、快速交付；同时基本都是基于 Web ，虽然开发技术可能差异很大（例如，
Java ＋＋、 .NET 等〉，但对外接口基本都是提供 HTTP ST削风格的接口，无须考
虑在接口层进行类似 SOA ES 样的处理
       缺点
           服务划分过细，服务间关系复杂
           服务数太多，团队效率急剧下降
           调用链太长，性能下降
           调用链太长，问题定位困难
           没有自动化支撑，无法快速交付
           没有服务治理，微服务数量多了后管理混
       最佳实践
           暂不研究
   微内核架构
       中文翻译为微内核架构，也被称为插件化架构（ Plug-in
Architecture ），是一种面向功能进行拆分的可扩展性架构，通常用于实现基于品（英文原文为
product based ，指存在多个版本、需要下载安装才能使用，与 web-based 相对应）的应用
       组成
           核心系统（ core system ）和插件模块（ plug-in modules
       设计关键点
           插件管理
               常见的就是注册表方式，注册表含有每个插件模块的信息，包括它的名字、位置、加载时机（启动就加载，还是
           插件链接
               插件连接指插件如何连接到核心系统。通常来说，核心系统必须制定插件和核系统的
连接规范，然后插件按照规范实现，核心系统按照规范加载即可
常见的连接机制有 OSGi CEcli pse 使用）、消息模式、依赖注入（ Spring 使用），甚至使
用分布式的协议都是可以的，比如 RPC HTTP Web 的方式
           插件通信
               插件通信指插件间的通信虽然设计的时候插件间是完全解稿的，但实际业务运行过程
中，必然会出现某个业务流程需要多个插件协作，这就要求两个插件间进行通信。由于
插件之间没有直接联系，通信必须通过核心系统，因此核心系统需要提供插件通信机制。
       OSGI架构
           是将 OSGi 当作个微内核的架构模式。
           Eclipse 3.0 版本开始，抛弃了原来自己实现的插件化框架，改用了 OSGi 框架。需要注
的是， OSGi 个插件化的标准，而不是个可运行的框架， Eclips巳采用的 OSGi 框架称为
Equinox 似的实现还有 Apache Felix Spring SpringDM
           组成
               模块层
                   模块层完成插件管理功能 OSGi 中，插件被称为 Bundle ，每个 Bundle 是一个 Java JAR
文件，每个 Bundle 里面都包含元数据文 MANIFEST.MF ，这个件包含了 Bundle
本信息。例如， Bundle 的名称、描述、开发商、 classpath ，以及需要导入的包和输出的包，等
等。 OSGi核心系统会将这些信息加载到系统用于后续使用。
               生命周期层
                   生命周期层完成插件连接功能，提供了执行时模块管理、模块对底层 OSG 框架的访问
生命周期层精确地定义了 bundle 生命周期的操作（安装、更新、启动、停止、卸载〕， Bundle
必须按照规范现各个操作
               服务层
                   服务层完成插件通信的功能。 OSGi 提供了一个服务注册的功能，用于各个插件将自己能提
供的服务注册到 OSGi 核心的服务注册中心，如果某个服务想用其他服务，则直接在服务注册中心搜索可用服务就可以了
       规则引擎架构
           规则引擎从结构上来看也属于微内核架构的种具体实现，其中执行引擎可以看作微内核，
执行引擎解析配置好的业务流，执行其中的条件和规则，通过这种方式来支持业务的灵活多变
           子主题 2

《从零开始学Swift》学习笔记（Day67）——Cocoa Touch设计模式及应用之MVC模式

原创文章，欢迎转载。转载请注明：关东升的博客

MVC（Model-View-Controller，模型-视图-控制器）模式是相当古老的设计模式之一，它最早出现在Smalltalk语言中。现在，很多计算机语言和架构都采用了MVC模式。

MVC模式概述

MVC模式是一种复合设计模式，由“观察者”（Observer）模式、“策略”（Strategy）模式和“合成”（Composite）模式等组成。MVC模式由3个部分组成，如图所示，这3个部分的作用如下所示。

模型。保存应用数据的状态，回应视图对状态的查询，处理应用业务逻辑，完成应用的功能，将状态的变化通知视图。
视图。为用户展示信息并提供接口。用户通过视图向控制器发出动作请求，然后再向模型发出查询状态的申请，而模型状态的变化会通知给视图。
控制器。接收用户请求，根据请求更新模型。另外，控制器还会更新所选择的视图作为对用户请求的回应。控制器是视图和模型的媒介，可以降低视图与模型的耦合度，使视图和模型的权责更加清晰，从而提高开发效率。