14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维

第14章 业务架构思维 
14.1 “伪”分层 
	典型的互联网分层架构:
		客户端 => 接入层 => 聚合层 => 业务层 => 基础服务层 => 数据层

	伪分层架构可能具有的一些特征:
		1.底层调用上层
			比如某个基础服务调用上层业务服务,怎么解决呢?
			
			办法1:要思考业务逻辑是否放错了地方?或者业务逻辑是否要一分为二,一部分放在业务服务,一部分放在基础服务。也就避免了底层调用上层。

			办法2:OOD 中的典型办法,DIP(依赖反转)。底层定义接口,上层实现,而不是底层直接调用上层。

		2.同层之间,服务之间各种双向调用
			比如业务服务1,业务服务2,业务服务3 之间都是双向调用。

			这时候就要思考,业务服务1,业务服务2,业务服务3 之间的职责分配是否有问题,出现了服务之间的紧耦合。

			是否应该有一个公共的服务,让公共服务和业务服务1,业务服务2,业务服务3 交互,而三个业务服务之间互相独立。

		3.层之间没有隔离,参数层层传递,一直穿透到最底层,导致底层系统经常变动
			例如,APP一直发版,为了实现兼容,服务器有类似下面的代码:
				if (version = 1.0)
					xxx
				else if (version = 2.0)
					xxx
				else 
					xxx

			这个例子比较明显,一看就知道是客户端的东西,所以通常在服务的业务入口做了拦截,不应该透传到了最底层服务。但很多业务层面也会遇到类似的
		问题,但不容易看出来,需要很好的抽象能力才能发现。

			比如客户端要支撑各种各样的业务,肯定有类似 businessType 这样的字段用于区分不同的业务,或者说区分同一业务的不同业务场景。
		businessType 字段一直穿透到最底层的基础服务,在基础服务里面能看到 if businessType = xxx 这样的代码,这就是典型的上层的业务多样性
		透传到了底层。

			虽然是严格分了层,层层调用,但"底层服务"已经不是底层服务,因为每一次业务变动都会导致从上到下跟着一起改。

		4.聚合层特别多,为了满足客户端需求,各种拼装
			遇到这种情况,往往意味着业务服务层太薄,纯粹从技术角度拆分了业务。而不是从业务角度然让服务成为一个完整的闭环,或者说一个领域。

	一个优秀的分层架构应该具有的典型特征如下:
		1.越底层的系统 越单一,越简单,越固化;越上层的系统花样越多,越容易变化。要做到这一点,需要层与层之间有很好的隔离和抽象。
		2.做到了上面一点,也就容易做到层与层之间严格的遵守上层调用下层的准则。

14.2 边界思维 
	所有的架构思维模式中,如果说最终只能留下一种思维模式,那就是边界思维。"优雅的接口,龌龊的实现"。在技术领域,"封装","面向接口的编程"等技术,
也都是边界思维的体现。只要一个系统对外的接口是简洁,优雅的,即使系统内部混乱,也不会影响外部系统。相当于把混乱的逻辑约束在一个小范围内,而不会扩散
到所有系统。
	
	边界思维是一种通用的思维方式,下面从小到大来看边界思维在不同层面的体现:
		1.对象层面(SOLID原则)
			在面向对象的五大原则中,第一个原则 S 就是单一职责原则(The Simgle Responsibility Principle)。通俗地讲,就是一个函数,一个类,
		一个模块只做一件事情。不要把不同的职责杂糅在一起,这就是边界思维的体现。

			当然,这里说的"一件事情"是从同一个抽象层次来说的。对一个类来说,里面所有的函数都处在同一个抽象层次中,不要让一个函数做两个函数的事情;
		对于一个模块来说,里面所有的类处于同一个抽象层次中。

		2.接口层面
			对于开发人员来说,做一个系统往往先看如何实现。而利用边界思维,首先想到的不是如何实现,而是把系统当做一个黑黑盒,看系统对外提供的接口是
		什么。接口也就是系统的边界。接口定义了系统可以支持什么,不支持什么。所以,接口的设计往往比接口的实现更重要。站在使用者的角度来看,并不在意
		接口如何实现,而更在意接口的定义是否清晰,使用是否方便。具体来说,就是:接口的输入,输出参数分别是什么?哪些参数是可选的,哪些是必选的?如果
		输入参数很多,为什么不是分成多个接口?设计策略是什么?接口是否幂等?各种异常场景,接口的返回结果是什么。

		3.产品层面
			对于产品,常说的一句话是:内部实现很复杂,用户界面很简单。

		4.组织架构层面
			组织的各个部门之间如果没有非常清晰的边界,就会导致该自己做的事情,互相推诿;不该做的事情,抢着做。

		回到系统,不管用哪种分析方法和设计方法,最终必须保证每个系统有清晰的边界,各种分工清晰。无论谁要了解系统,他不用看这个系统的实现,只要看
	系统的接口,就知道系统支持什么,不支持什么。

		边界思维的重点在于"约束",是一个"负方法"的思维模式。什么意思呢?比如要看一个开源的软件,要看的不是它能做什么,而是它不能做什么。不能做什么
	决定了系统的边界,或者说它的"极限"。

		做架构尤其如此,架构强调的不是系统能支持什么,而是系统的"约束"是什么,不管是业务约束,还是技术约束。没有约束,就没有架构。一个设计或系统,
	如果"无所不能",则意味着"一无所能"。

14.3 系统化思维 
	与边界思维相对应的是系统化思维。不能头痛医头,脚痛医脚。

	系统化的思维,把不同的东西串在一起,而不是割裂后分开来看。另外一个体现是,遇到问题要刨根到底,直至事物的本质。这点在物理学中叫做"第一性原理"。


14.4 利益相关者分析 
	做一个系统与做一个产品一样,首先要了解用户是谁,在架构里面称为利益相关者。

	以"黑盒"的方式思考:在考虑利益相关者时,考虑的系统范围可大,可小。在大的方面,把公司所有系统都放在一起看,当做一个黑盒子,看外部系统有哪些利益
相关者;小的方面,可以只看一个系统里面的一个子系统,一个模块,看其外部都有系统。
	
	为什么谈业务架构,要先谈"利益相关者"呢?
		1.利益相关者其实是从"外部"来看系统。把系统当做一个黑盒子,看为哪几类人服务。这其实也就定义了整个系统的边界,定义了整个系统做什么和不做什么。
		2.前面说到一个词"业务",业务具有"闭环"的特点。而利益相关者就是一个最好看待业务的视角。
		3.每个利益相关者代表了一个视角。站在C端用户的视角和B端商家的视角,对系统有不同的看法。系统很复杂,无法从一个角度全面看问题,每个视角都是
		盲人摸象,只能看到系统的一部分。
		4.利益相关者往往也对应了一种业务划分,系统划分。根据不同的利益相关者,可以划分出不同的系统和业务。

14.5 非功能性需求分析(以终为始) 
	软件有功能需求和非功能需求,FURPS需求模型。

	非功能需求有:
		1.并发性
			衡量指标有 tps 和 qps,平均响应时间/最大响应时间,并发数。

		2.可用性
			从服务角度,一个服务不可用有2层意思:
				1.机器宕机,不能对外提供服务,直接抛错;
				2.机器虽然没有宕机,但是超时。这涉及"性能"问题。

		3.一致性
			比如数据库的参照完整性,事务,缓存与数据库数据同步,多备份数据一致性问题。

		4.稳定性和可靠性
			"稳定性"指系统没有任何未定义的行为,体现在如下几方面:
				1.所有的 if-else 语句里面,没有不处理的分支;
				2.所有的api调用,每种异常返回值都有处理;
				3.考虑内存,磁盘的上限;
				4.系统不会时不时冒出一个问题;
				5.出了问题,有很好的日志监控,能快速修复问题;
				6.系统的qps不会有抖动(除非业务有变化,如大促),是一条平滑的曲线;
				7.发布新版本,有回滚方案;
				8.新系统上线,灰度平滑切换;
				9.Monkey Test?压力测试;
				...

		5.可维护性
			1.系统架构设计简单,接口简洁,表数据关系清晰;
			2.老人离职,新人接手,无需很长时间就能厘清代码逻辑;
			3.系统功能不耦合,改动一个地方不会牵动全身;
			4.系统某些模块即使时间久远,也有人能厘清内部逻辑;
			...

		6.可扩展性
			1.来了一个新需求,伴随着一些新功能,可以在现有的系统上灵活扩展;
			2.没有地方写死,可以灵活配置;
			3.容易变化的逻辑没有散落在各个系统里面,不需要多个地方跟着一起改。

		7.可重用性
			开发新的需求,旧的功能模块可以直接拿过来用。

		通常来讲,对于C端应用,会关注高并发和高可用,然后有的业务(比如支付)对一致性要求非常高;对于B端业务,会更关注系统的可维护性,可扩展性,
	可重用性,有了这些特性,系统才不能拖业务后腿,可以快速的支撑各种各样的复杂业务需求的开发。

		上面是想说明做架构的一种"以始为终"的思维方式。先明确落脚点,或者说最终要达到的目的,即非功能性需求,再去想要达到这些目的可以用哪些技术
	手段。只要能达到目的,可以用各种办法。

14.6 视角(横看成岭侧成峰) 
	架构的4+1视图:
		其中的1是指 "功能视图",其他4个视图都是围绕该视图展开的,分别是逻辑视图,物理视图(部署视图),开发视图,运行视图(进程视图)。

		功能视图:
			对于B端的复杂业务系统,往往会画用例图,但对于C端产品,往往直接看 交互设计稿或最终的UI原型图。

		逻辑视图:	
			系统的逻辑模块划分,数据结构,面向对象的设计方法论里面的 类图,状态图等。

		物理视图:
			整个系统所在的机房,各类机器数目,机器配置和网络带宽等。

		开发视图:
			代码所在的工程结构,目录结构,Jar包,动态链接库,静态链接库等。

		运行视图:
			系统的多进程,多线程之间的同步。

		除了4+1视图,还有一个常见的视图"数据视图",称为5+1视图。逻辑视图和数据视图有什么区别?

			逻辑视图是一个比数据视图更加宽泛的概念,在传统的以数据库为中心的开发中,数据视图也就是 E-R 模型,同时也是逻辑视图,所谓的"贫血模型";
		在领域驱动设计中(DDD),提倡"充血模型",逻辑视图往往指的是类图,在其他的非数据库的系统中,逻辑模型也可能是指内存中的数据结构。

			另外还有一个问题,微服务的拆分是架构的逻辑视图,还是物理视图,还是开发视图?微服务既反映了一种逻辑上的拆分,同时也对应了一种部署,同时
		也是一种开发方式。可以把多个微服务部署在一台机器上,也可以把一个微服务部署到多台机器上。

			讨论这些不同的架构视图,是想说明一个关键的问题:视图本身只是一个框,一个形式,引导开发者把系统的架构描述清楚,而重点是系统面对的问题
		描述清楚,而不是拘泥于形式本身,并且不同类型的系统的侧重点也不同,也未必每个视图都需要很清楚的描述。否则,架构就是一个"空架子",虽然视图
		很多,但没有阐释关键问题。


14.7 抽象 
	1.什么是抽象
		1.语言中的抽象
			语言的抽象阶梯。语言只是对现实中我们所注意到的事务特征的一种抽象,每一次命名,都是一个抽象化的过程,这种过程忽略了现实中事物的许多
		特征。

			从阿花,牛,家畜,农庄资产,资产,财务,就组成了一个抽象阶梯,抽象程度越来越高,而其中的组成部分的细节特征显示的也越来越少,到后来
		真实的特性也就完全不提了。

			所以,抽象是一个化繁为简的过程,也是一个"可能性,多样性越来越小"的过程;抽象的过程也是一个总结,分门别类的过程。

		2.计算机中的抽象
			1.存储的抽象:关系型数据库,表格。
			2.计算的抽象是顺序,选择,循环。再复杂的算法,逻辑计算到了计算机里面,最终都会变成顺序,选择,循环三种语句。
			3.面向对象的方法学:父类与子类,继承。
			4.面向接口的方法学

			把面向对象的方法再往前推进一步,就是所谓的"面向接口的方法学"。接口是双方交互的一种协议,也是对交互细节的一种抽象。

	2.怎么做抽象
		1.分解:找出差异和共性。
			要做抽象,首先要做的是分解。只有分解,才知道两个事务之间的差异和共性。

		2.归纳:造次。
			找到了共性和差异,把共性的部分总结成一个新的东西,造出一个新词来表达"共性",就是归纳,也是抽象。所以抽象的过程往往也是一个"造次"
		的过程。

	3.抽象带来的问题
		抽象的好处是找出共性,简化事物,但抽象也会造成问题。
			1.抽象造成意义模糊
			2.抽象错误:地基不稳
			3.抽象造成关键特性丢失
			4.抽象过程

14.8 建模 
	软件领域的建模:面向对象建模,业务建模,领域建模,UML建模,ER实体建模,四色建模法,DCI ...

	建模的本质到底是什么:
		1.建模的本质:重要的东西"显性化"
			很多时候会遇到重要的情况:一个函数写了几百行代码,里面的if-else 写了很多,计算各种业务规则。另外一个人接手后,分析了好几天,才把
		业务逻辑彻底理解清楚。

			这个问题从表面上来看是代码写的不规范,要重构,把一个有几百行代码的函数拆成一个个小的函数。从根本上来说,就是"重要逻辑"隐藏在代码里面,
		没有"显性"的表达出来。

			这只是一个函数,推广到类,模块,系统,是同样的道理,比如:
				1.业务流程隐藏在多个对象的复杂调用关系里面;
				2.某个业务的核心概念没有提取出来,其职责分摊到了其他几个实体里面;
				3.系统耦合,职责边界不清...

			所以,建模的本质是:把重要的东西进行显性化,进而把这些显性化的构造块互相串联起来,组成一个体系。

		2.重要的东西:构造块
			哪些东西是"重要"的呢?比如领域实体,某个业务流程(对应领域驱动设计里面的"领域服务"),比如某条重要的业务规则(对应领域驱动设计里面的
		Specification模式),比如复杂对象的创建过程(对应领域驱动设计里面的工厂模式)...

			说白了,就是把系统里面"重要的"东西挑出来,让它在"设计图纸"上可见,而不是分析完代码才能看出来。

		3.显性化
			重要的东西找到了,如何显性化呢?其实就是"命名"。"名不正言不顺",名字反应了职责,名字也让领域专家,架构师,程序员对"同一个东西"进行
		讨论,而不是"牛头不对马嘴"。

		4.形成体系
			找到了"重要的东西"并"命名成构造块",接下来就是通过某种结构把这些"构造块"组装起来,成为一个整体,这就成了某种"方法论"。

		5.建模的层次
			不仅做业务分析才有建模,即使没有任何的业务建模,直接写一个超级大的函数,里面包含所有代码,这何尝不是一种建模呢?只不过这种"建模"的
		构造块太小:加减乘除,if-else,for,while ... 这些就是这种建模方法的构造块,并且这种方法对于程序员尤为擅长。

			把建模范式应用到不同的粒度,不同的层次的建模方法:
				1.自然语言建模
					构造块:常用的几千个汉字
					语法规则:主谓宾定状补

				2.计算机语言建模
					构造块:加减乘除,if-eles,for,while...
					语法规则:程序员很熟悉。

				3.过程建模
					构造块:函数
					语法规则:整个系统描述成一个个过程,每个过程通过函数的层层调用组成。

				4.对象建模
					构造块:对象
					语法规则:整个系统描述成对象与对象之间的关系。

				5.领域驱动设计建模
					构造块:实体,值对象,领域服务,领域事件,聚合根,工厂,仓库,限定上下文
					语法规则:"构造块"之间的联系(不是很明显,需要深入研究,也正是领域驱动设计难掌握的地方)。

14.9 正交分解 
	比"分解"更为严谨,更为系统的是"正交分解"。

	在物理学中的傅立叶变换,任意一种形状的波形都可以由一系列标准的正弦波叠加而成,这也是正交分解。分解的过程要保证2个原则:
		1.分清。同一层次的多个部分之间要互相独立,无重叠。
		2.分净。完全穷尽,无遗漏。

		每种分法之间互不重叠,同时又完全穷尽所有的人。

	案例1:电商的供应链来说,一个很重要的就是仓库。极大核心业务:
		1.采购
		2.退供
		3.调拨
		4.售卖
		5.客退

		这些业务的业务流程和逻辑都很像,站在仓库的角度,如何支撑这些业务呢?其中一个思维就是正交分解:虽然业务种类繁多,但站在仓库的角度,只有2种
	操作:"入库"和"出库"。

	案例2:电信公司的套餐种类繁多,但拆解来看,主要有电话,短信,宽带3种。

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第1张图片

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第2张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第3张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第4张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第5张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第6张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第7张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第8张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第9张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第10张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第11张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第12张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第13张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第14张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第15张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第16张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第17张图片 14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第18张图片

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第19张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第20张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第21张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第22张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第23张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第24张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第25张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第26张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第27张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第28张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第29张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第30张图片 

14.软件架构设计:大型网站技术架构与业务架构融合之道 --- 业务架构思维_第31张图片 

 

 

 

你可能感兴趣的:(架构,架构,postman,linq)