弹吉他的兔子
0、软件研发全生命周期
低代码为企业提供了“降本、增效、提质”的价值。
降本、增效、提质，就是为企业降低研发成本、人力成本，提升研发效率，缩短产品交付周期，加快企业试错的速度，降低试错成本。使得企业的产品和服务以更快的速度进行迭代和优化，在激烈的市场竞争中胜出。
低代码平台的使用者中，约 67% 的人是 IT 开发者，剩下的则是业务人员，需要掌握需求分析、业务建模、代码调试、模块测试、发布和运维等工作，这些并非一个普通业务人员能够胜任的。
低代码仍然需要大量的专业程序员，只是低代码平台把程序员从低效的、没有技术含量的CRUD当中解放出来，做更有价值、更高效的软件开发工作。比如：业务建模、领域建模、数据结构设计、业务流程设计、业务系统调试和部署等等。
低代码的主要使用者仍然是程序员，通过低代码平台完成：
- 需求分析、
- 业务建模、
- 代码调试、
- 模块测试、
- 发布和运维
实现软件研发全流程的提效。
1、项目与需求的区别
- 项目是有明确的目标，边界项目范围，这个过程人员会进行相对封闭式的、相对集中的开发；
- 需求是相对开放的，今天做需求A，明天做需求B
从个人成就感来说，项目更能帮助你明确的成长，有明确的目标，你更能有大块的时间去做一件事；而需求就相对零碎，为了做需求还要了解项目的背景业务应用，时间被多个需求切割，需求是业务方提出的零碎的，对于点状的实现。
项目是业务方提出的，需要立项，评估可行性，投入产出比。
项目管理：有明确的项目目标，项目边界，在开发过程中，管好进度、风险，并且理出计划，然后达到预期目的。尽量避免临时变更需求。
项目的过程中，要考虑安全性，可靠性，系统是不断演化进化的。
2、调用第三方
使用manager模块，防腐层
红黑树的根节点，自己与自己比较的意图，就是为了放第一个节点，确定这个对象具有可比较性，有两种方式：
- 自己实现比较
- 使用比较器来比较
3、系统鲁棒性
鲁棒性怎么理解，举一个笑话说明：有一个程序猿在叹气，这个代码为什么就运行不起来了，可是过了一阵子，他又点了一次运行，这个代码怎么就运行起来了。当一个代码运行不起来和运行起来的时候，你都觉得很神奇的时候，那么这个代码就是缺乏鲁棒性的。
鲁棒性：指代码在正常的时候能运行，在不正常的时候一定能运行
鲁棒是Robust的音译，也就是健壮和强壮的意思。它也是在异常和危险情况下系统生存的能力。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性
系统的复杂就体现在分布式、高可用、高性能上，当他们单机版的时候都是简单的
为了保证系统的鲁棒性，就要做容灾：
-
限流
用户分层限流，当流量大的时候，我确保VIP用户可以使用，小白用户就不可以使用
地域限流，比如说新疆的用户，网络链路又长，用户又少，可以进行部分限流
针对特性的功能接口进行限流
-
降级
打个比方，我开个饭店，生意很好，来了很多客人，会员可以进，非会员不可以进，这就是限流了；平常都是服务员给你倒茶、拿筷子、上菜的，由于客人非常多，服务员忙不过来，部分客人就只能自己倒茶，拿餐具，菜做好后，自己去餐台窗口拿菜，这就是降级；我在隔壁又开了一家饭店，对面又开一家饭店，万一有一家出现什么情况不能服务客人，就可以让客人去隔壁的饭店就餐，这就是灾备
-
灾备
技术的最优解并不是商业的最优解，有时候就希望产品出现故障不能用，促进新的消费。
4、架构图
架构师
架构设计的目的是为了降低系统的复杂性，
架构师的职责是消除不确定性和降低复杂性
架构师不能只顾技术，不懂业务
架构师的三个核心能力
-
判断
业务理解能力
技术能力
沟通能力
-
拆解
技术深度
技术宽度
技术广度
-
取舍
设计理念
说服能力
决断能力
架构设计的几个阶段
架构设计前期，就是跟相关干系人员开会，与业务方开会
架构设计中期，设计备选方案，选择备选方案，内部开会，写文档，汇报
架构设计后期，细化架构方案，交给开发团队实现
架构验证阶段，·收集架构意见：开发人员、测试人员、运维人员意见
什么是架构图
我们经常说画架构图，那什么是架构图
从严格意义上说，区分为业务架构图、产品架构图、技术架构图3个层面
-
业务架构图：侧重于表达业务方想要什么，一般是运营端画的；
-
产品架构图：侧重于把业务进行产品层面的抽象，梳理共性，来形成产品架构，一般是产品经理画的；
-
技术架构图：侧重于体现技术实现上跟功能的结合地带，简单的说就是使用相应的技术栈实现对应的功能，一般是架构师画的；
我们通常的说技术架构图，就是抽象的表示某个系统的产品和技术，即水平方向上的业务单元+垂直方向上的技术依赖形成的混合逻辑结构图。回想一下，架构图的样子包含：
- 上面是功能单元
- 中间是服务层
- 模块的抽象层
- 缓存
- 数据库
参考：
画好架构图
怎么把框框的技术架构图画好，其实是挺难的事情。首先要表达出层次，可以使用颜色来区分，当我使用明显的颜色如红色去表达框、线的时候，这部分一定是核心的东西，当我使用灰色不显眼的颜色去表达框、线的时候，一般是外部依赖。
1）画架构图的颜色布局：
- 显眼的颜色表达自己的东西，灰色等不显眼的颜色表达别人的东西外部依赖
2）画架构图的方向布局：
- 从左到右表达业务的单元，如下单-> 支付-> 我的订单
- 从上往下表达技术的依赖
3) 画架构图的规划年限
-
3-5年的规划
5年以后，新的技术框架迭代很快，你现在想的框架很好，很可能5年后就是被淘汰的技术
3年以内，太短，导致项目经常重构，浪费人力物力
4）考虑架构的4大目的
-
确定系统边界
哪个功能做，哪个功能不做，
-
确定模块的内部关系，你的系统与外部依赖的关系
模块内有哪些API，与外部依赖关系的有哪些API
-
确定指导你的系统后续演化的原则
与外部接口通过防腐层调用，模块对不对外，模块的安全性
搞清楚模块之间的关系，也就是类之间的关系
- 继承
- 依赖
- 组合
- 实现
- 聚合
- 关联
面向对象的特征：封装、继承、多态
轮子与汽车车体的关系是：聚合，类图中用黑色的菱形表示
确定模块之间的关系，就是分任务
-
确定系统的非功能性需求
5、上手架构设计
4R架构指Rank 、Role、Relation、Rule
4+1架构视图
-
逻辑视图
logical view 描述系统提供给用户的功能，对应UML class 类图 和状态图 state diagrams
-
处理视图
process view 描述系统的处理过程，对应UML的sequence 和 activity 图
-
开发视图
Development veiw 描述程序员视角看系统的逻辑组成，对应UML的package 图
-
物理视图
Physical veiw 描述系统工程师视角看系统的物理组成，对应UML的部署图deployment diagrams
-
场景视图
Scenarios 描述用户角度看系统需要实现的需求，对应UML的用例图 user case diagrams
国内企业很少用4+1视图描述架构，因为
1）4+1视图是1995年 Philippe kruchten在《IEEE Software》提出，那时候是单体系统时代，现在大多数都是分布式系统了，无法满足描述现在复杂的架构；
2）4+1视图是绑定UML图去画我们的架构图的，比较丑
3）理解困难，容易混淆
举例：
左边UML画的架构示意图，右边使用ppt画的架构示意图可以使用颜色的图标，就比较好看，有更好的表达
架构图分类
简单来说，客户端与前端都是一台设备上的，比如说手机或一台电脑上部署一个应用程序，而后端它是在多台服务器上部署很多个应用程序，比如nginx、业务数据库、业务应用等。客户端与前端基本上不存在像后端这么复杂的划分，还有不同的技术，所以说客户端和前端的架构一般情况下只会按照模块划分。
业务架构
从业务的角度去划分你的系统，可以得到业务架构，它描述了系统对用户提供了什么业务功能，也就是4+1的场景视图
举例，香港支付宝钱包的业务架构图：
MTR：香港地铁
人传人：你可以邀请你的好友来使用AlipayHK来获得一些红包
使用场景
- 产品人员规划业务
- 给新员工汇报业务
- 给新员工培训业务
画图技巧
-
通过不同颜色来标识业务状态
比如说你可以用颜色来标识业务是不是已经比较稳定了，还是说现在在快速发展
比如说某个颜色可以标识这个业务今年才开始做的，已经在规划，明年要做的
-
业务分组管理（业务相似性、关联性一组）
像上面分了4组：钱包业务、第三方业务、商家服务、用户管理
它的目的是把相关的业务放在一起，能够更方便的识别出整个业务的一个结构和它的状态。分组要有一个明确的要求，这些业务它本质上是要有一定的类似性的。
客户端与前端架构
定义
本质上都是针对客户端领域或者前端领域，按照逻辑的领域划分的，类似于4+1视图的逻辑视图
举例
使用场景
-
整体架构设计
比如，你代表你们的技术团队，跟产品团队、其他部门或者是业界的技术大会上进行分享
-
架构培训
新员工培训，与其他部门技术交流可以用这个客户端架构、前端架构
画图技巧
- 通过不同颜色来标识不同角色
- 通过连接线来表示关系relation
系统架构
定义
后端的逻辑架构，也叫后端架构、技术架构
举例，MongoDB的系统架构
首先看里面的角色：Router 、Config Server、Shard
再看里面的关系：Router 会访问Config Server，Config server 同时管理Router、Shard，Router也会访问Shard来拿数据，同时每个Shard 主分片可以有1个或者多个副本分片叫replica set。
这就是MongoDB整体分片的系统架构图
使用场景
-
整体架构设计
系统设计的核心
-
架构培训
画图技巧
- 通过不同颜色来标识不同角色
- 通过连接线来表示关系relation
为什么后端的逻辑架构直接就叫系统架构？
一个系统的架构核心的部分，它的重点其实就在后端架构，所以一般说系统架构主要就是讲它的后端架构
系统架构复杂难以表达，画2张图
这个是一个钱包中台的案例
功能示意图：
从逻辑的角度去划分整个中台架构，它能够看出系统里面的包含的角色，但是Relation关系即这些角色之间的关系没有清晰的表达出来，所以就需要我们再画一张交互图，如下：
交互示意图
通过这两张图就可以清晰的看出整个钱包中台的系统架构。
应用架构
容易与系统架构混淆，他的定义是：描述后端系统由哪些应用组成。什么是应用，你在开发、打包、测试、部署的时候，一个可执行的程序叫一个应用
上面会员中心是一个业务域，它包含了6个应用如LoginServer，这每个Server都是你开发出来然后部署上线的一个程序包，可以独立运行的一个应用。
问题来了：为什么需要一个单独的应用架构
看它的使用场景
-
项目开发、测试中，不是直接使用系统架构，而是应用架构，因为我们的团队，包括开发、测试、运维团队，它负责维护的一个单元，其实是一个应用，而不是整体的一个领域，不管你是打包、测试、部署，其实最终都是针对一个个的应用，所以我们需要一个应用架构图来指导我们项目开发过程中的开发测试和部署
-
部署发布
-
子域架构设计
做子域的架构设计的时候，比如上面的会员中心，最后你要拆分出这些应用，不同的应用要提供什么样的接口，对应哪一个需求，每个应用要做什么，都是要在应用架构里面体现的。
就像之前做的国内营销系统重构项目，结算中心是整个系统的一个子域，还包括其他子域：交易中心、政策中心、基础中心等。
其中结算中心分5个应用：smc结算应用、mcc收款应用、cdc信用应用、rcc对账应用、ivc发票开票应用。
画图技巧
- 通过不同颜色来标识不同角色
- 通过连接线来表示关系relation
应用架构与系统架构的区别和联系在哪里？
-
简单来说有时候，它们可以是等价的。比如MongoDB的系统架构与应用架构，因为它的划分方式就是一个应用对应系统里面的一个角色，比如Router就是一个角色，也是一个应用，Config Server和Shard也是如此
-
有时候，它们不相等，如上面举例的中台案例。
看你这个架构的复杂度有多大，一般来说像MongoDB这种中间件，复杂度不大，基本上应用架构就是系统架构。
但是你说做支付中台、电商中台，复杂度大，需要把应用架构与系统架构分开
部署架构
定义
描述后端系统具体如何部署，对应4+1视图的物理视图
首先北京机房里部署了Nginx，下面有Web服务器的集群，存储这块有MySQL集群、Hadoop集群；
还有一个深圳镜像机房，它的结构是跟北京机房是一样的；
还有对接外部的系统，如银行、便利店，它们都是通过网络加速点来接入我们的机房。
区别
前面的前端架构、系统架构都是用这个区块来代表这个角色，但是在部署架构里面，为了直观与比较形象的展现部署架构，尽量使用图标，比如说服务器的图标，存储的图标
6、系统序列图
为什么需要系统序列图
我们回顾一下4R架构的定义： Rank 级别、Role角色、Relation关系、Rule规则
前面讲的客户端前端架构图、系统架构图，还有部署架构图，都是描述Role 跟 Relation的，我们称之为静态架构图，它是没办法描述运作规则的，这就是动态架构图需要实现的目的。
这是前面讲支付中台的系统架构时的交互示意图
这个图只是描述了各个中心角色之间的关系，但是具体一个业务或者一个需求的处理流程是怎么样的，就需要系统序列图去描述具体的一个业务场景时如何实现的。
我们可以看一下下面这个系统序列图：扫码支付流程图
总结：
1) 什么是好的设计方案？
你设计的目的为了迎合变化点，解耦合
2) 知识 = 40%装B(体现你的学习能力) + 30%用来解决问题 + 30%用来协同沟通 3) 学过的知识、理论一定要内化成为自己的知识，记住知识最大作用并不是解决问题，而是建立自己的知识品牌和理论势能，其次才是合理高效地解决问题。
作为一个后端，要做表设计ER图、功能示意图、交互示意图、场景序列图。