https://www.processon.com/view/link/5e51378ce4b0c037b5f9d1e3#outline
架构学习
架构本质
通过合理的内部编排，保证系统高度有序，能够不断扩展，满足业务和技术的变化。
首先，架构的出发点是业务和技术在不断复杂化，引起系统混乱，需要通过架构来保证有序。
其次，架构实现从无序到有序，是通过合理的内部编排实现的，基本的手段，就是“分”与“合”，先把系统打散，然后将它们重新组合，形成更合理的关系。
分类
业务架构：概念
业务架构就是讲清楚核心业务的处理过程，定义各个业务模块的相互关系，它从概念层面帮助我们理解系统面临哪些问题以及如何处理
应用架构：逻辑
应用架构就是讲清楚系统内部是怎么组织的，有哪些应用，相互间是怎么调用的，它从逻辑层面帮助我们理解系统内部是如何分工与协作的
技术架构：物理
技术架构就是讲清楚系统由哪些硬件、操作系统和中间件组成，它们是如何和我们开发的应用一起配合，应对各种异常情况，保持系统的稳定可用。
好的架构要求
业务复杂性
满足业务的可扩展、可复用
技术复杂性
满足系统的高可用、高性能和可伸缩，并尽量采用低成本的方式落地。
好的架构师要求
TA 必定是一个出色的程序员，写的一手好代码
需要有思维的高度，具备抽象思维能力
思维的深度，能够透过问题看本质：一个跨网络调用，知道数据是如何通过各种介质（比如网卡端口）到达目标位置
具备良好的沟通能力（感性）
良好的平衡取舍能力（理性）
业务架构
概念
产品和业务架构师区别
产品经理的职责就是：告诉用户，系统长什么样子；告诉开发，他要实现什么功能。
对业务架构师来说，TA 的工作，就是把业务流程和节点打散，按照业务域的维度来划分系统模块，并定义这些模块之间的关系，最终形成一个高度结构化的模块体系。
业务架构目标
业务的可扩展
业务的主题是变化和创新，系统的主题是稳定和可靠。
业务的可复用
按照业务域来划分业务，把业务流程中的节点拆分到各个业务域，按照业务域构造系统模块
模块要求
模块的职责定位要非常清晰
模块的数据模型和接口设计要保证通用
实现模块的高复用，还需要做好业务的层次划分
可扩展架构
概念
何为系统？即 模块 + 关系
对模块的要求：
1、定位明确，概念完整；
2、自成体系，粒度适中
对关系的要求：
1、同时简化依赖的方向和减少依赖的数量；
2、我们要尽量把网状结构转化为层次结构，模块结构层次化是简化模块依赖关系的有力手段。
如何打造可扩展架构
该系统本质是：通过构建合理的模块体系，有效地控制系统复杂度，最小化业务变化引起的系统调整。
实现方法：通过拆分，实现模块划分；通过整合，优化模块依赖关系
拆分：一般做业务架构时，我们先考虑垂直拆分，从大方向上，把不同业务给区分清楚，然后再针对具体业务，按照业务处理流程进行水平拆分
整合：
1、通用化整合：通用化指的是通过抽象设计，让一个模块具备通用的能力，能够替代多个类似功能的模块。
2、平台化整合：平台化是把定位相同的模块组织在一起，以组团的方式对外提供服务。对于外部系统来说，我们可以把这些模块看成是一个整体，一起对业务场景提供全面的支撑。
案例一:电商平台的架构演变
单体架构 2000年
特点
单体应用内部一般采用分层结构，从上到下，一般分为表示层、业务层、数据访问层、DB 层。
单体架构在水平方向上，通过层次化的划分，降低了业务的深度复杂性；
不过在垂直方向上，单体应用缺乏清晰的边界，上下层模块之间是多对多的网状依赖关系
在单体架构中，模块结构是否合理，很大程度上依赖于开发者的个人水平。
架构图
优点
快速落地
项目初期，适应快速验证市场
弊端
业务系统的体量变大时，弊端就会暴露
1、多团队并行开发的话，需要额外的资源来协调不同团队之间的并行开发和上线。
2、代码合并和编译非常复杂
分布式 2006年
特点
分布式架构，简单来说就是系统由多个独立的应用组成，它们互相协作，成为一个整体。
在分布式架构中，API 接口属于应用的一部分，它和表示层共享底层的业务逻辑
把一个大系统的业务复杂度，分割成多个小业务的复杂度，从而降低了整体的复杂度。
分布式架构适用于业务相关性低、耦合少的业务系统
架构图
优点
通过拆分后，各个应用之间的耦合度低，就可以很好地支持多团队的并行开发。
弊端
作为应用的开发者，除了要满足自身业务的需求之外，同时还需要考虑外部业务的需求，这两部分经常会打架。
每个应用都是从头到尾，自搭一套完整的体系，导致业务之间重复造轮子，造成资源浪费。
SOA 2009年
Service Oriented Architecture
传统SOA
目的
它解决的是企业内部大量异构系统集成的问题
特点
让各个系统通过提供标准的服务，来满足外部调用需求。
外部系统通过这个服务访问系统内部，解决不同系统相互集成的问题
架构图
新 SOA
目的
它解决的是系统重复建设的问题
特点
它通过服务化思想，提供更好的业务封装性，并通过标准技术，能更友好地对外输出业务能力；
SOA 服务不依附于某个具体应用，它可以独立地部署和扩展，这样避免了直接影响现有的系统；
服务通过封装通用的业务逻辑，可以供所有应用共享，解决了重复造轮子的问题。
架构图
弊端
然而 SOA 服务化的思想很好，但在系统实现上比较重，落地比较困难。
微服务 2014年
特点
相对于SOA架构，思想是相似的，但是架构更轻，但两者不同的地方在于，微服务是去中心化的，不需要 SOA 架构中 ESB 的集中管理方式。这就需要不同的通讯方式
每个微服务，都是负责端到端的业务
包括前端的 UI 展现部分和后端业务逻辑。由这个小团队负责应用的整个生命周期管理。
从一定程度上说，微服务叫做微应用，微产品，是拆分得更细的分布式架构
微服务强调围绕业务，进行清晰的业务和数据边界划分，并通过良好定义的接口输出业务能力
微服务强调所谓的哑管道，通过 HTTP 等简单的技术手段就可以访问
微服务强调智能终端，所有的业务逻辑包含在微服务内部，不需要额外的中间层提供业务规则处理
架构图
微服务 = 小应用 + 小服务
实际而言侧重小服务
很难把一个大系统，按照端到端业务的方式，拆分为一个个应用
需要把现有的职能团队打散后重组，这种人员组织的调整实际上也很难落地。
实践方法：弱化微服务的小应用定位，然后扩大化微服务小服务的定位
封装底层基础业务的是共享微服务
封装流程的是聚合微服务
封装具体业务场景的服务端是应用微服务
封装基础中间件（如 Redis 缓存、消息推送）的是系统微服务
中台 2018年
产生背景
概念
前台指的是面向 C 端的应用，比如像微信、淘宝这样的应用，后台指的是企业内部系统，比如 ERP、CRM、仓库管理系统等等
冲突
前台和后台的特性是不一样的。前台对外，我们知道，消费者的需求快速多变，所以前台需要能快速响应，做到低成本试错；而后台对内，企业内部的业务流程不能经常变，所以后台需要稳定，不能随意调整
解决方案
前台和后台是企业 IT 系统的一体两面，它们需要紧密协作，共同服务于企业的业务战略，如何实现前后台的平滑对接，这是一个巨大的挑战，中台架构因此而生
中台适用场景
示意图
要求
1、这和公司业务线的数量有关，业务线越多，意味着重复建设的成本会更大，当我们开始上第 3 条业务线时，就应该要考虑转到“山”字形了
2、和各个业务线的相似度有关，相似度越高，意味着业务线之间有更多类似的逻辑
优势
从业务角度来看，中台收敛了业务场景，统一了业务规则
从系统角度看，中台相当于操作系统，对外提供标准接口，屏蔽了底层系统的复杂性
从数据角度看，中台收敛了数据，比如使用同一套订单数据模型，让所有渠道的订单使用相同的订单模型
总结：通过实现基础业务的平台化，实现了企业级业务能力的快速复用。
中台落地模式
互联网企业
架构图
特点
松散的微服务 -> 共享服务体系 -> 中台，这是微服务架构向中台架构的演进过程。
基础业务能力由通用基础业务平台来实现；另外，通用聚合服务对基础业务进行组合，进一步提升了业务能力的易用性；而通用中间件平台，通过技术手段保证了业务中台的稳定性，三者一起实现了企业整体业务能力的复用
优点
微服务升级为了商品中心、订单中心，每个中心更强调体系化，包括更好的业务通用能力，更好的系统运营能力（如监控、稳定性、性能的强化），更好的业务运营能力（比如商品中心自带配套的商品管理后台）。
传统企业
架构图
特点
渠道 & 应用层，这是整个系统的对外部分，包括了各个应用的前端，如 App、小程序、公众号等等
应用平台是各个具体应用的母体，它包含了各个应用的服务端，做流程编排和信息的聚合。中间网关实现前后端隔离，具体负责外部访问的安全验证和监控，以及内外部请求的路由和消息格式转换。
业务中台是中台架构的核心，它包括一系列的通用基础服务
后台包括两部分，第一部分是适配插件，用于连接商户内部系统和中台基础服务；第二部分是企业内部系统，这个是企业的 IT 基础设施，业务最终会在这里落地。
优点
中台代表了企业核心的业务能力，它自成体系，能够为 C 端的互联网场景提供通用的能力，并通过各种插件和后台打通
案例二：一号店app端架构演变
可复用架构
概念
案例一：如何设计一个基础服务
案例二：如何对现有系统做微服务改造
案例三：中台如何练成
技术架构
概念
高可用架构
概念
案例一：实现O2O平台24小时在线
案例二：如何第一时间知道系统哪里有问题
案例三：打造一体化监控系统
高性能和可伸缩架构
概念
高性能架构案例
可伸缩架构案例
一个综合案例：互联网平台技术架构演变
总结篇
架构原则汇总
汇总图
可回滚/可禁用
可回滚原则确保了系统可以向后兼容，当系统升级出现问题的时候，我们可以回滚到旧版本，保证系统始终可用。
如果数据库的新旧表结构差异很大，除了回滚代码，我们还要回滚数据库，这样操作起来往往需要很长时间，系统的可回滚性就比较差。
可禁用原则要求我们提供功能是否可用的配置，在系统出现故障时，我们能够快速下线相应的功能。比如说，新的商品推荐算法有问题，我们可以通过程序开关禁用这个功能。
使用成熟的技术
一方面，要从系统的稳定性出发，尽量选择成熟的技术，避免因为新技术的坑而导致系统可用性出现问题；
另一方面，选择成熟的技术也意味着选择了团队熟悉的技术，这样学习成本低，落地快。
使用同质化硬件
我们选择同样的 CPU 和内存配置，以及同样的操作系统版本，这样我们更容易通过统一的自动化脚本，对节点进行配置，对系统做水平扩展时也会更加容易。
架构落地过程
架构师职责
构师的职责就是负责设计架构，并跟踪架构的实施过程，解决过程中出现的疑难问题，确保架构顺利落地
架构师工作阶段
架构师要和产品经理或者业务人员沟通，了解业务；和开发人员沟通，了解系统。
设计方案
架构师针对业务需求，分解相应功能到现有的各个系统，把系统的各个部分串起来，这个第一版的方案至少要能够在表面上解决当前的问题，这样就形成一个草根的方案。
架构师要进一步深入思考业务的本质，对现有的草根方案进行升华，比如说，通过抽象，让方案更加通用，可以解决多个类似的或潜在的业务需求，这样，草根的方案就变成了一个高大上的方案，这里很考验架构师的透过问题看本质和抽象总结的能力
基于现有的各项约束，比如时间、资金和人员技术能力等因素，架构师要对方案进行简化，把高大上的方案变成一个接地气的方案，以最小的代价实现最大的价值，这里很考验架构师的平衡取舍能力
进行宣讲，架构师需要说服相关的人员接受方案，并且在后续的方案执行中，负责跟踪架构的落地，如果过程中有疑难问题，架构师还要协助解决。
架构师知识结构
知识结构图
具体技术
第一部分是开发相关的基本知识，比如数据结构和算法、具体的开发语言、常用的设计模式以及开发框架等等，这样你就具备了基本的开发能力
第二部分是各种中间件知识，常用的中间件包括数据库、缓存、消息系统、微服务框架等等，对于这些核心中间件，我们不但要了解具体的用法，还要深入理解它们的适用场景。这样你就能写出高效健壮的代码，能够独立承担一个子系统的开发。
你还要学习分布式系统相关的知识，包括底层网络和分布式通信技术，这样你就可以了解系统是怎么连接在一起的。除此之外，你还要了解一些周边的系统，比如大数据平台、运维监控系统、接入系统等等，这样，你就可以了解系统端到端的运行过程，从技术架构上保证系统的稳定可用。
架构师成长路径
java为例的学习内容
初级开发阶段
你需要深入学习数据结构和算法，并且一定要深入掌握单体应用的分层架构，因为这是架构设计的基础。
对 JDK 的一些核心类，你不能仅仅停留在使用层面，而是要深入研读源代码，了解它的内部设计。这样你就知道如何开发一个高效的程序，如何进行各种代码级的调优
高级开发阶段
你需要非常了解设计模式，每个设计模式都可以看做是一个小型的架构设计，这里面有很好的设计原则和抽象思维，你在做系统设计时可以借鉴它们。
你需要非常了解核心的中间件，包括 DB、微服务框架、缓存和消息系统，要清楚地了解它们的适用场景（比如消息系统的削峰、解耦和异步），知道如何对它们进行调优，以及了解它们都有哪些常见的坑等等，核心中间件是我们做技术选型的基础。
你要深入掌握数据库设计和服务接口设计，了解它们的最佳设计实践，它们承载了系统核心的业务数据和业务逻辑。
你需要进一步研读源码，源码是活的教材，它包含了大量实用的设计原则和技巧。这里我建议你选择一些开源的开发框架和 RPC 通信框架，去深入了解它们内部的实现原理，比如 Spring 和 Netty。
架构师阶段
你需要深入了解网络通信，比如说网络分层和 HTTP/TCP 协议，还有各种常见的 RPC 通讯框架，了解它们的特性和适用场景，这样你在设计分布式系统时，就能够进行合理的技术选型。
了解底层系统，包括 JVM、操作系统和硬件原理，再往上延伸到系统的接入部分，了解常见的负载均衡特性和用法
需要熟练掌握各种设计工具和方法论，比如领域驱动设计和 UML，了解常用的架构设计原则
大师阶段
还要对运维和监控有深入的认知
了解业界的架构实践，跟踪技术的发展趋势，如果出来一项新技术，你可以比较准确地对它进行定位，把它纳入到自己的能力体系当中
架构师境界
第一层看山不是山
刚接手项目的时候，你对业务还不太了解，经常会被业务方冒出的术语弄得一愣一愣的，如果把现有问题比作山，那就是横看成岭侧成峰，你根本摸不透，此时看山不是山。
第二层看山是山
经过业务梳理和深入了解系统以后，你能够设计出一个简单的方案，把各个系统串起来，能解决当前的问题，对当前的这个“山”能够看清楚全貌，此时就做到了看山是山。
第三层看山不是山
通过进一步抽象，你能够发现问题的本质，明白了原来这个问题是共性的，后续还会有很多类似的问题。然后你就对设计进行总结和升华，得到一个通用的方案，它不光能解决当前的问题，还可以解决潜在的问题。此时，你看到的已经是问题的本质，看山不是山
第四层看山是山
最后回到问题本身，你能够去除过度的抽象，给出的设计简洁明了，增之一分嫌肥，减之一分嫌瘦，既能解决当前的问题，又保留了一定的扩展能力，此时问题还是那个问题，山还是那个山
若有收获，就点个赞吧
0 人点赞
