13.软件架构设计：大型网站技术架构与业务架构融合之道 --- 业务意识

Posted 2022-01-03 enlyhua

第13章 业务意识 
13.1 产品经理vs.需求分析师 
	技术不是无源之水，一旦离开业务纯粹的谈技术，就失去了驱动技术发展的根本要素。另外一方面，研发部门的人力资源和时间是有限的，而业务需求是无限的，
要用有限的资源应对无限的需求，必然存在需求取舍的问题，而这种取舍往往会有影响系统的架构设计。	
	
	具有良好的业务sense是做业务架构的基本条件，什么叫业务意识，这里抛出几个问题：
		1.需求来自何处
			如果是一个C端的互联网产品，需求可能来自 用户反馈或用户调研；如果是一个B端的产品，需求可能直接来自客户；还有可能，需求来自业务数据的
		分析挖掘，从数据中发现了某些问题需要解决；更有可能，需求来自老板的决定。

			有时候，需求来自何处，技术为谁而做，往往和公司的基因，盈利模式紧密挂钩，公司本身决定了需求从什么地方来。

		2.真需求还是伪需求
			技术人员通常会听到要开发一个某某功能，一个某某系统，但"功能"和"系统"并不是需求。需求是要解决的"问题"，而问题一定是系统所要面对的用户
		问题或客户问题，功能或系统只是解决问题的一种答案而已。

			很多原因都会导致伪需求，比如老板的决定，面向kpi的需求，这些都比较容易看到。但下面介绍一种稍微隐形的原因：信息传播的递减效应。

			一个需求被提出来，可能经过总监，组长，产品经理层层传导，到技术人员这，可能已经不是最初的需求了，最后做出来的东西往往不是对方真正想要的。
		所以，作为一个技术人员，当从产品经理接到需求的时候，一定要回溯，明确需求在什么背景下提出来的，究竟要解决用什么问题。

		3.产品手段 vs. 技术手段
			对于业务问题，产品经理可能会考虑产品手段，技术人员可能会考虑技术手段。

		4.需求的优先级
			人力资源是有限的，一个需求很重要，还是不那么重要，是很紧急，还是可以从缓，需要有清晰的认识。系统的架构是被需求驱动着一步步迭代，升级的，
		只有非常清楚需求的轻重缓急，才不至于出现设计不足或者过度设计的问题。


13.2 什么叫作一个“业务” 
	一个内容是否算作是"业务"往往与公司的长期战略，盈利模式，发展阶段，组织架构密切相关，并没有一个标准的划分方式。但抛开这些差异性，一个内容能
称为"业务"，往往具有一个特点，就是"闭环"。
	
	什么叫闭环：
		1.团队闭环：有自己的产品，技术，运营和销售，联合作战；
		2.产品闭环：从内存的生成到消费，整条链路把控；
		3.商业闭环：具备了自负盈亏的能力；
		4.纵向闭环：某个垂直领域，覆盖从前到后；
		5.纵向闭环：平台模式，纵向覆盖某个横切面。


13.3 “业务架构”的双重含义 
	业务架构：支撑业务的技术架构。

	业务架构关乎组织架构，也关乎技术架构，所以很有必要讨论 业务架构，组织架构和技术架构三者之间的关系。
		1.先说业务架构的第一重意思。
			从理论上说，合理的团队的组织架构应该是根据业务的发展来决定的。不同的公司在不同的发展阶段会根据业务的发展情况，将壮大的业务拆分，
		萎缩的业务合并。拆分到一定阶段的时候又合并，组织架构相应的随着调整，相应的技术团队跟着整合，技术架构自然也会跟着变化。
			这种变化规律就是"康威定律"：一个组织产生的系统设计等于组织之内，组织之间的沟通结构。这意味着：如果组织架构不合理，则会约束业务架构，
		也约束技术架构的发展。而组织架构的调整涉及部门利益的重新分配，所以往往也只能由高层推动。

		2业务架构的第二重意思。
			"支持业务的技术架构"，业务架构和技术架构会互相作用，互相影响。这种技术的思考会反过来影响业务，重新思考团队的组织方式，团队的组织方式
		又会变，接下来又会影响业务的发展方式。


13.4 “业务架构”与“技术架构”的区分 
	之所以要谈到"分"，是因为经常遇到的情况是：明明是业务问题，却想要用技术手段解决；明明是技术问题，由于技术无法实现，反过来将就业务；可能既不是
业务问题，也不是技术问题，而是组织架构问题，是部门利益问题，是公司的盈利模式问题。
	
	下面列举了技术架构要关心的问题：
		1.你的系统是在线系统还是离线系统？
		2.如果是在线系统，需要拆分成多少个服务？每个服务的QPS是多少，需要部署多少台机器？
		3.运行的方式是多线程，还是多进程，还是线程同步机制，进程同步机制？
		4.如果是离线系统，有多少个后台任务？任务是单机，还是集群？
		5.对应的数据库的表设计？是否有分库分表？
		6.数据库的高可用？主从切换？
		7.服务接口的API设计？
		8.是否用了缓存？缓存数据结构是怎样的？缓存数据的更新机制？缓存的高可用？
		9.是否用了中间件？消息的消费策略？
		10.是否有限流，降级，熔断的措施？
		11.监控，报警？
		12.服务之间的数据一致性如何保证？比如分布式事务。
		...

	从上面一系列问题可以看出来，技术架构涉及的问题都是"系统"，"服务"，"接口"，"表"，"机器"，"缓存"这样技术性很强的词语。

	把上面的内容梳理一下，归类并起个名字，就变成我们经常挂在嘴边的各种架构词汇：
		1.物理架构(物理部署图)；
		2.运行架构(多进程，多线程)；
		3.数据架构(数据库表的schema)；
		4.应用架构(系统的微服务划分)；
		...

	这些都是从不同"视角"得出的归类，组合在一起就是经常讲的 软件架构4+1 视图。技术，再到业务，所用的词汇越来越抽象。