学架构摘要
文章平均质量分 85
极客课程《从0开始学架构》摘要
yolo_sec
学习、思考、实践、总结、改进、交流
展开
-
架构设计文档模板参考
目录备选方案模板需求介绍需求分析5W1H8C复杂度分析高可用高性能可扩展备选方案备选方案评估架构设计模板总体方案架构总览核心流程详细设计高可用设计高性能设计可扩展设计安全设计其他设计部署方案架构演进规划以类微博功能的消息队列为例,给出架构设计中最重要的两个文档的模板和关键说明。这个案例文档仅给出一些关键内容供参考,部分细节无法全面覆盖或者完全保证正确。备选方案模板需求介绍需求介绍主要描述需求的背景、目标、范围等随着业务的不断发展,业务上拆分的子系统越来越多,目前系统间的调用都是同步调用,由此带来几原创 2022-05-15 13:50:00 · 932 阅读 · 0 评论 -
谈谈App开发的演进
目录web app原生appHybrid Appweb app最早的 App 有很多采用这种架构,大多数尝试性的业务,一开始也是这样的架构。Web App 架构又叫包壳架构,简单来说就是在 Web 的业务上包装一个 App 的壳,业务逻辑完全还是 Web 实现,App 壳完成安装的功能,让用户看起来像是在使用 App,实际上和用浏览器访问 PC 网站没有太大差别。Web App 这种包壳架构主要解决快速开发和低成本两个复杂度问题,设计遵循合适原则和简单原则。原生appWeb App 虽然解决了快速原创 2022-05-08 11:02:21 · 174 阅读 · 0 评论 -
系统重构的注意点
目录有的放矢沟通协调合纵连横分段实施优先级排序问题分类先易后难循序渐进相比全新的设计来说,重构相对更复杂,主要体现在:业务已经上线,不能停下来;关联方众多,牵一发动全身,如何尽量减少对关联方的影响,或者协调关联方统一行动,是一项很大的挑战;旧架构的约束,重构需要在旧的设计基础上进行,这是一个很强的约束,会限制选择范围,即使是推倒重来,完全抛弃旧的而去设计新的,新设计也会受到旧设计的约束和影响,因为业务在旧方案上产生的数据是不能推倒重来的,新设计必须考虑如何将旧方案产生的数据转换过来。有的放矢原创 2022-04-30 23:51:11 · 725 阅读 · 0 评论 -
互联网平台技术了解
这里写自定义目录标题欢迎使用Markdown编辑器新的改变功能快捷键合理的创建标题,有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能,丰富你的文章UML 图表FLowchart流程图导出与导入导出导入欢迎使用Markdown编辑器你好! 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Mar原创 2022-04-17 10:00:46 · 514 阅读 · 0 评论 -
互联网开发用户层和业务层技术了解
目录用户层技术用户管理单点登录授权登录消息推送存储云、图片云用户层技术用户管理单点登录各个子系统统一登录。单点登录的技术实现手段较多,例如 cookie、JSONP、token 等,目前最成熟的开源单点登录方案当属 CAS,其架构如下授权登录允许第三方应用接入,现在最流行的授权登录就是 OAuth 2.0 协议,基本上已经成为了事实上的标准。用户管理系统面临的主要问题是用户数巨大,用户数据量虽然大,但是不同用户之间没有太强的业务关联,A 用户登录和 B 用户登录基本没有关系。因此虽然数据量巨原创 2022-04-03 09:52:49 · 3268 阅读 · 0 评论 -
互联网开发网络层技术了解
目录负载均衡DNSNginx 、LVS 、F5CDN多机房多中心当我们站在一个公司的的角度来思考架构的时候,单个系统的高可用和高性能并不等于整体业务的高可用和高性能,互联网业务的高性能和高可用需要从更高的角度去设计,这个高点就是“网络”,所以我将相关措施统一划归为“网络层”。注意这里的网络层和通常理解的如何搭建一个局域网这种概念不一样,这里强调的是站在网络层的角度整体设计架构,而不是某个具体网络的搭建。负载均衡将请求均衡地分配到多个系统上DNSDNS 是最简单也是最常见的负载均衡方式,一般用来实现原创 2022-03-26 11:52:22 · 2805 阅读 · 0 评论 -
互联网开发层和服务层技术了解
目录开发层技术开发框架WEB服务器容器服务层技术配置中心服务中心服务名字系统服务总线系统两者对比消息队列开发层技术开发框架互联网业务发展的一个特点:复杂度越来越高。复杂度增加的典型现象就是系统越来越多,不同的系统由不同的小组开发。如果每个小组用不同的开发框架和技术,则会带来很多问题,典型的问题有:技术人员之间没有共同的技术语言,交流合作少;每类技术都需要投入大量的人力和资源并熟练精通;不同团队之间人员无法快速流动,人力资源不能高效的利用所以,互联网公司都会指定一个大的技术方向,然后使用统一原创 2022-03-19 17:38:20 · 335 阅读 · 0 评论 -
互联网存储层技术了解
目录SQLNoSQL小文件存储大文件存储SQL业务发展到一定阶段后,需要拆库拆表来满足业务的进一步发展,一般做法是将这部分功能独立成中间件,如百度的 DBProxy、淘宝的 TDDL,开源方案如 MySQL的 MySQL Router、360 开源的 Atlas。假如业务继续发展,规模继续扩大,SQL 服务器越来越多,如果每个业务都基于统一的数据库中间件独立部署自己的 SQL 集群,就会导致新的复杂度问题,具体表现在:数据库资源使用率不高,比较浪费;各 SQL 集群分开维护,投入的维护成本越来越原创 2022-03-12 11:40:53 · 1730 阅读 · 0 评论 -
互联网技术演进了解
目录业务复杂性初创期发展期堆功能优化竞争期成熟期用户规模性能可用性量变到质变互联网业务千差万别,但由于它们具有“规模决定一切”的相同点,其发展路径也基本上是一致的。互联网业务发展一般分为几个时期:初创期、发展期、竞争期、成熟期。不同时期的差别主要体现在两个方面:复杂性、用户规模业务复杂性互联网业务发展第一个主要方向就是业务越来越复杂。初创期互联网业务刚开始一般都是一个创新的业务点,这个业务点的重点不在于完善,而在于创新,只有创新才能吸引用户;而且因为其新的特点,其实一开始是不可能很完善的。只有随原创 2022-03-04 18:32:53 · 2254 阅读 · 0 评论 -
技术更新迭代的金箍棒
目录个人决策者决策的因决策的方向本文性质是笔记重点,而原文谈的是决策者角色,故下文个人角色仅供参考个人个人喜爱技术,那么你也是乐于了解各种新技术的;技术的迭代升级,是解决某方面的问题或者改善原有的不足缺陷之类;限于个人认知,基础技术级的突破是较难的,需要理论的支撑;更多还是架构或方案设计上的迭代升级,工程业务上的优化解决方案;在了解熟悉基础理论的基础上,面对技术的迭代,了解学起来不会很头疼,还会很开心的;决策者面对新技术一般有三种表现:潮流派潮流派的典型特征就是对于新技术特别热衷原创 2022-02-26 11:46:14 · 7024 阅读 · 0 评论 -
微内核结构了解
目录基本结构设计关键点插件管理插件连接插件通信基本结构微内核架构包含两类组件:核心系统(core system)和插件模块(plug-in modules)。核心系统负责和具体业务功能无关的通用功能,例如模块加载、模块间通信等;插件模块负责实现具体的业务逻辑。微内核的架构本质就是将变化部分封装在插件里面,从而达到快速灵活扩展的目的,而又不影响整体系统的稳定。设计关键点微内核的核心系统设计的关键技术有:插件管理、插件连接和插件通信插件管理核心系统需要知道当前有哪些插件可用,如何加载这些插件,什原创 2022-02-12 15:00:25 · 1274 阅读 · 0 评论 -
微服务实践
目录方法篇服务粒度拆分方法基于业务逻辑拆分基于可扩展拆分基于可靠性拆分基于性能拆分基础设施基础设施篇方法篇服务粒度针对微服务拆分过细导致的问题,我建议基于团队规模进行拆分,类似贝索斯在定义团队规模时提出的“两个披萨”理论(每个团队的人数不能多到两张披萨都不够吃的地步),分享一个我认为微服务拆分粒度的“三个火枪手”原则,即一个微服务三个人负责开发。为什么是 3 个人,不是 4 个,也不是 2 个呢?首先,从系统规模来讲,3 个人负责开发一个系统,系统的复杂度刚好达到每个人都能全面理解整个系统,又能够原创 2022-02-05 18:23:02 · 476 阅读 · 0 评论 -
微服务与SOA
目录微服务与SOA的关系服务粒度服务通信服务交付应用场景总结微服务的陷阱服务划分过细,服务间关系复杂服务数量太多,团队效率下降调用链太长,性能下降调用链太长,问题定位困难没有自动化支撑,无法快速交付没有服务治理,微服务数量多了后管理混乱参考维基百科,简单梳理一下微服务的历史2005 年:Dr. Peter Rodgers 在 Web Services Edge 大会上提出了“Micro-Web-Services”的概念;2011 年:一个软件架构工作组使用了“microservice”一词来描述一种原创 2022-01-29 12:24:39 · 828 阅读 · 0 评论 -
分层架构和SOA
目录分层架构C/S架构、B/S架构MVC 架构、MVP 架构逻辑分层架构总结SOA服务ESB松耦合总结分层架构分层架构是很常见的架构模式,它也叫 N 层架构,通常情况下,N 至少是 2 层。例如,C/S 架构、B/S 架构。常见的是 3 层架构(例如,MVC、MVP 架构)、4 层架构,5 层架构的比较少见,一般是比较复杂的系统才会达到或者超过 5 层,比如操作系统内核架构。按照分层架构进行设计时,根据不同的划分维度和对象,可以得到多种不同的分层架构C/S架构、B/S架构划分的对象是整个业务系统,原创 2022-01-22 10:36:03 · 2464 阅读 · 0 评论 -
软件系统的可扩展
目录扩展的基本思想—拆面向流程拆分面向服务拆分面向功能拆分扩展方式软件系统与硬件和建筑系统最大的差异在于软件是可扩展的,一个硬件生产出来后就不会再进行改变、一个建筑完工后也不会再改变其整体结构。相比之下,软件系统就完全相反,如果一个软件系统开发出来后,再也没有任何更新和调整,反而说明了这套软件系统没有发展、没有生命力。真正有生命力的软件系统,都是在不断迭代和发展的,典型的如 Windows 操作系统。扩展的基本思想—拆拆,就是将原本大一统的系统拆分成多个规模小的部分,扩展时只修改其中一部分即可,无须整原创 2022-01-16 23:36:00 · 3180 阅读 · 0 评论 -
应对业务高可用问题
目录系统级故障-异地多活类型同城异区跨城异地跨国异地技巧保证核心业务的异地多活保证核心数据最终一致性采用多种手段同步数据只保证绝大部分用户的异地多活步骤第 1 步:业务分级第 2 步:数据分类第 3 步:数据同步第 4 步:异常处理接口级故障降级熔断限流排队系统级故障-异地多活类型异地多活:指不同地理位置上的系统都能够提供业务服务。判断一个系统是否符合异地多活,需要满足两个标准:正常情况下,用户无论访问哪一个地点的业务系统,都能够得到正确的业务服务;某个地方业务异常的时候,用户访问其他地方正常的原创 2022-01-08 17:39:21 · 1340 阅读 · 0 评论 -
计算高可用回顾
目录主备主从集群对称集群非对称集群计算高可用的主要设计目标是当出现部分硬件损坏时,计算任务能够继续正常运行,因此计算高可用的本质是通过冗余来规避部分故障的风险。关键点如下两点:哪些服务器可以执行任务第一种方式,每个服务器都可以执行任务,例如常见的网站访问;第二种方式,只有特定的服务器(主机)可以执行任务,如zookeeper的leader才能处理写请求;任务如何重新执行第一种策略是对于已经分配的任务即使执行失败也不做任何处理,系统只需要保证新的任务能够分配到其他非故障服务器上执行即可;原创 2022-01-02 23:38:28 · 790 阅读 · 0 评论 -
数据高可用存储回顾
数据高可用存储,双机,集群,数据分区原创 2021-12-25 16:30:58 · 1874 阅读 · 0 评论 -
使用FMEA来分析系统的可用性
目录FMEA(Failure mode and effects analysis,故障模式与影响分析)又称为失效模式与后果分析,是一种在各行各业都有广泛应用的可用性分析方法,通过对系统范围内潜在的故障模式加以分析,并按照严重程度进行分类,以确定失效对于系统的最终影响。FMEA 最早是在美国军方开始应用的,20 世纪 40 年代后期,美国空军正式采用了 FMEA。尽管最初是在军事领域建立的方法,但 FMEA 方法现在已广泛应用于各种各样的行业,包括半导体加工、餐饮服务、塑料制造、软件及医疗保健行业。原创 2021-12-05 23:36:16 · 369 阅读 · 0 评论 -
数据一致性相关理论学习
目录一致性(Consistency)可用性(Availability)分区容忍性(Partition Tolerance)应用CP - Consistency/Partition ToleranceAP - Availability/Partition ToleranceCAP 定理(CAP theorem)又被称作布鲁尔定理(Brewer’s theorem),是加州大学伯克利分校的计算机科学家埃里克·布鲁尔(Eric Brewer)在 2000 年的 ACM PODC 上提出的一个猜想。2002 年,原创 2021-11-28 23:48:56 · 1183 阅读 · 0 评论 -
负载均衡的分类和算法
目录DNS负载均衡硬件负载均衡软件负载均衡负载均衡方式组合负载均衡算法轮询加权轮询负载最低优先性能最优类Hash类单服务器无论如何优化,无论采用多好的硬件,总会有一个性能天花板,当单服务器的性能无法满足业务需求时,就需要设计高性能集群来提升系统整体的处理性能。高性能集群的复杂性主要体现在需要增加一个任务分配器,以及为任务选择一个合适的任务分配算法。高性能集群的本质很简单,通过增加更多的服务器来提升系统整体的计算能力。由于计算本身存在一个特点:同样的输入数据和逻辑,无论在哪台服务器上执行,都应该得到相原创 2021-11-21 16:00:48 · 671 阅读 · 0 评论 -
单服务器高性能:PPC、TPC、epoll、Reactor、Proactor
目录PPCpreforkTPCprethreadReactorProactor高性能架构设计主要集中在两方面:尽量提升单服务器的性能,将单服务器的性能发挥到极致;如果单服务器无法支撑性能,设计服务器集群方案;除了以上两点,最终系统能否实现高性能,还和具体的实现及编码相关。但架构设计是高性能的基础,如果架构设计没有做到高性能,则后面的具体实现和编码能提升的空间是有限的。形象地说,架构设计决定了系统性能的上限,实现细节决定了系统性能的下限。单服务器高性能的关键之一就是服务器采取的并发模型,并发模型原创 2021-11-14 20:05:01 · 2003 阅读 · 2 评论 -
缓存雪崩缓存穿透和缓存热点问题
虽然我们可以通过各种手段来提升存储系统的性能,但在某些复杂的业务场景下,单纯依靠存储系统的性能提升不够的,典型的场景有:需要经过复杂运算后得出的数据,存储系统无能为力读多写少的数据,存储系统有心无力缓存就是为了弥补存储系统在这些复杂业务场景下的不足,其基本原理是将可能重复使用的数据放到内存中,一次生成、多次使用,避免每次使用都去访问存储系统。缓存能够带来性能的大幅提升,以 Memcache 为例,单台 Memcache 服务器简单的 key-value 查询能够达到 TPS 50000 以上,其原创 2021-11-07 16:14:52 · 265 阅读 · 0 评论 -
常见的NoSQL方案
目录K-V 存储关系库并不完美,存在一些缺点:关系数据库存储的是行记录,无法存储数据结构;关系数据库的 schema 扩展很不方便;关系数据库在大数据场景下 I/O 较高;关系数据库的全文搜索功能比较弱;针对上述问题,分别诞生了不同的 NoSQL 解决方案,这些方案与关系数据库相比,在某些应用场景下表现更好。但世上没有免费的午餐,NoSQL 方案带来的优势,本质上是牺牲 ACID 中的某个或者某几个特性,应该将 NoSQL 作为 SQL 的一个有力补充。常见的 NoSQL 方案分为 4原创 2021-10-10 23:53:22 · 427 阅读 · 0 评论 -
数据库之分库分表
目录业务分库读写分离分散了数据库读写操作的压力,但没有分散存储压力,当数据量达到千万甚至上亿条的时候,单台数据库服务器的存储能力会成为系统的瓶颈,主要体现在这几个方面:数据量太大,读写的性能会下降,即使有索引,索引也会变得很大,性能同样会下降;数据文件会变得很大,数据库备份和恢复需要耗费很长时间;数据文件越大,极端情况下丢失数据的风险越高;基于上述原因,单个数据库服务器存储的数据量不能太大,需要控制在一定的范围内。为了满足业务数据存储的需求,就需要将存储分散到多台数据库服务器上。业务分库业原创 2021-09-30 23:41:03 · 215 阅读 · 0 评论 -
数据库之读写分离
目录读写分离复制延迟分配机制程序代码封装中间件封装总结高性能数据库集群的第一种方式是“读写分离”,其本质是将访问压力分散到集群中的多个节点,但是没有分散存储压力;第二种方式是“分库分表”,既可以分散访问压力,又可以分散存储压力。读写分离读写分离的基本原理是将数据库读写操作分散到不同的节点上:读写分离的基本实现是:数据库服务器搭建主从集群,一主一从、一主多从都可以;数据库主机负责读写操作,从机只负责读操作;数据库主机通过复制将数据同步到从机,每台数据库服务器都存储了所有的业务数据;业务服务原创 2021-09-30 15:40:43 · 7836 阅读 · 0 评论 -
流程三详细方案设计
简单来说,详细方案设计就是将通过方案评估选择的最终方案涉及的关键技术细节给确定下来。例如,Nginx 的负载均衡策略:轮询(默认)每个请求按时间顺序逐一分配到不同的后端服务器,后端服务器分配的请求数基本一致,如果后端服务器“down 掉”,能自动剔除。加权轮询根据权重来进行轮询,权重高的服务器分配的请求更多,主要适应于后端服务器性能不均的情况,如新老服务器混用。ip_hash每个请求按访问 IP 的 hash 结果分配,这样每个访客固定访问一个后端服务器,主要用于解决 sessio原创 2021-09-18 14:43:52 · 120 阅读 · 0 评论 -
流程二备选方案及评估
目录误区设计最优秀的方案只做一个方案备选方案过于详细评估和选择评估选择绝大部分时候我们有了明确的目标后,对已经被验证过的成熟技术按图索骥就能够找到可选的解决方案。只有当这种方式完全无法满足需求的时候,才会考虑进行方案的创新,而事实上方案的创新绝大部分情况下也都是基于已有的成熟技术。在《技术的本质》一书中,对技术的组合有清晰的阐述:新技术都是在现有技术的基础上发展起来的,现有技术又来源于先前的技术。将技术进行功能性分组,可以大大简化设计过程,这是技术“模块化”的首要原因。技术的“组合”和“递归”特征,原创 2021-09-18 14:13:10 · 1110 阅读 · 0 评论 -
流程一识别复杂度
前文中有说明架构设计的本质目的是为了解决软件系统的复杂性,所以在我们设计架构时,首先就要分析系统的复杂性。只有正确分析出了系统的复杂性,后续的设计方案才不会偏离方向。架构的复杂度主要来源于高性能、高可用、可扩展等几个方面,但在具体判断复杂性的时候,不能生搬硬套,认为任何时候架构都必须同时满足这三方面的要求。实际上大部分场景下,复杂度只是其中的某一个,少数情况下包含其中两个,如果真的出现同时需要解决三个或者三个以上的复杂度,要么说明这个系统之前设计的有问题,要么可能就是判断出现了失误,即使真的认为要同时满足原创 2021-09-12 23:59:01 · 132 阅读 · 0 评论 -
架构设计三原则
目录合适原则简单原则结构的复杂性逻辑的复杂性演化原则合适原则合适原则宣言:合适优于业界领先真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的,能够合理地将资源整合在一起并发挥出最大功效,并且能够快速落地。踩坑点:将军难打无兵之仗,没那么多人,却想干那么多活;罗马不是一天建成的,没有那么多积累,却想一步登天;冰山下面才是关键,没有那么卓越的业务场景,却幻想灵光一闪成为天才;简单原则简单原则宣言:简单优于复杂复杂在制造领域代表先进,在建筑领域代表领先,但在软件领域,却恰恰原创 2021-09-05 23:24:20 · 90 阅读 · 0 评论 -
复杂度来源之成本、安全和规模
目录低成本安全功能安全架构安全规模低成本当我们设计高性能、高可用的架构时,通用的手段都是增加更多服务器来满足要求;而低成本正好与此相反,我们需要减少服务器的数量才能达成低成本的目标。因此,低成本本质上是与高性能和高可用冲突的,所以低成本很多时候不会是架构设计的首要目标,而是架构设计的附加约束。也就是说,我们首先设定一个成本目标,当我们根据高性能、高可用的要求设计出方案时,评估一下方案是否能满足成本目标,如果不行,就需要重新设计架构;如果无论如何都无法设计出满足成本要求的方案,那就只能找老板调整成本目标了原创 2021-08-28 17:44:24 · 184 阅读 · 0 评论 -
复杂度来源之可扩展性
目录预测变化应对变化方案一方案二可扩展性指系统为了应对将来需求变化而提供的一种扩展能力,当有新的需求出现时,系统不需要或者仅需要少量修改就可以支持,无须整个系统重构或者重建。在软件开发领域,面向对象思想的提出,就是为了解决可扩展性带来的问题,后来的设计模式,更是将可扩展性做到了极致。设计具备良好可扩展性的系统,有两个基本条件:正确预测变化、完美封装变化。但要达成这两个条件,本身也是一件复杂的事情。预测变化预测变化的复杂性在于:不能每个设计点都考虑可扩展性;不能完全不考虑可扩展性;所有的原创 2021-08-28 17:21:23 · 147 阅读 · 0 评论 -
复杂度来源之高可用
目录计算高可用单机变双机复杂一点存储高可用高可用状态决策独裁式协商式民主式维基:系统无中断地执行其功能的能力,代表系统的可用性程度,是进行系统设计时的准则之一系统的高可用方案五花八门,本质上都是通过冗余来实现高可用。如:一台机器不够就两台,两台不够就四台;一个机房可能断电,那就部署两个机房。高性能增加机器目的在于扩展处理性能;高可用增加机器目的在于冗余处理单元。高性能虽然复杂,但是只要通过合理的集群方案还是可以解决业务的性能需求,但是高可用也只能做到相对高可用,绝对高可用是不存在的,总会有诸多突原创 2021-08-28 16:54:38 · 93 阅读 · 0 评论 -
复杂度来源之高性能
目录高性能单机复杂度集群复杂度任务分配任务分解高性能软件系统中高性能带来的复杂度主要体现在两方面,一方面是单台计算机内部为了高性能带来的复杂度;另一方面是多台计算机集群为了高性能带来的复杂度。单机复杂度计算机内部复杂度最关键的地方就是操作系统。操作系统是软件系统的运行环境,操作系统的复杂度直接决定了软件系统的复杂度操作系统和性能最相关的就是进程和线程。1一般我们要完成一个高性能的软件系统,需要考虑如多进程、多线程、进程间通信、多线程并发等技术点,而且这些技术并不是最新的就是最好的,也不是非原创 2021-08-14 11:58:58 · 156 阅读 · 0 评论 -
架构设计的目的
可以看到,整个软件技术发展的历史,其实就是一部与“复杂度”斗争的历史,架构的出现也不例外。简而言之,架构也是为了应对软件系统复杂度而提出的一个解决方案,通过回顾架构产生的历史背景和原因,我们可以基本推导出答案:架构设计的主要目的是为了解决软件系统复杂度带来的问题。...原创 2021-08-13 19:42:04 · 272 阅读 · 0 评论 -
软件架构出现的历史背景
架构设计的关键思维是判断和取舍,程序设计的关键思维是逻辑和实现。There is no silver bullet. 1为何结构化编程、面向对象编程、软件工程、架构设计最后都没有成为软件领域的银弹?软件本身的复杂度难以度量,随时间和规模发展,原有的解决方案很快难适应,人们就不断总结经验模式和设计解决新困难的办法,但是不管什么样的架构设计都是在尽量满足适应我们可能遇到的问题的解决方案,不是解决问题方案。生活中我们的应用从单体到主备再到集群、分布式、微服务等,这些其实都是解决和改善、完善、优化我们在软件原创 2021-08-07 18:07:09 · 200 阅读 · 0 评论 -
架构需要了解的概念
架构设计的关键思维是判断和取舍,程序设计的关键思维是逻辑和实现。目录系统与子系统模块与组件框架与架构系统与子系统维基定义:系统泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能单独完成的工作的群体。关联:没有关联的个体堆在一起不能成为一个系统;规则:规则规定了系统内个体分工和协作的方式;能力:系统能力不是个体能力之和,而是产生了新的能力。子系统也是由一群有关联的个体所组成的系统,多半会是更大系统中的一部分。以微信为例说明:微信本身是一个系统,包含聊天、登录、支付、朋友原创 2021-08-07 17:39:57 · 104 阅读 · 0 评论