阅读笔记-读《一线架构师实践指南》有感
什么是架构?为什莫要进行架构?怎样进行架构?这三个问题基本可以涵盖本书全部内容。为什莫我会如此大胆的说——因为这三个问题已经包含了架构的意思,有边界,有层次,分工明确,这些部分之间能够进行有机的联系,合并组装成为一个整体,完成目标的所有工作。这是我对全书的概念与认知路线,下面对第三部分Refined Architecture阶段进行探讨:
对于什么是架构?每个角色都有自己的关注点,不同涉众看待软件架构的视角自然也是不同的。不过也不是无迹可寻,大致可以从五个角度来划分:逻辑(职责划分) 物理(物理节点安排) 开发(程序单元组织) 数据(持久化设计) 运行(控制流组织)。也就是五视图,每个试图,一个思维,一组技术关注。这便是细化架构。
架构最重要的一点,就是它能把难以处理的大问题分解成便于管理的小问题。就划分子系统策略,可归纳为3种:
分层的细化:可简单地概括为MVC模式,模型(model)-视图(view)-控制器(controller),它们各自处理自己的任务
分区的引入:引入分区,以便于支持深度优先的迭代开发
机制的提取:基于具体类的协作则算不上机制、基于具体类的协作则算不上机制、基于接口(或抽象类)的协作是机
制,实现不同的最终功能可以重用同一个机制。
而划分子系统的依据4个重要原则:
职责不同的单元划归不同子系统
通用性不同的单元划归不同子系统
需要不同开发技能的单元划归不同子系统
坚固工作量的相对均衡,进一步切分太大的子系统
协作决定接口,"分"是手段,"合"是目的,不能合在一起支持更高层次功能的模块,有何用?
设计模式是基础,要站在各个角度看软件架构。并且通过质疑“对不对”和“好不好”,可以发现新职责,或者调整协作方式。
逻辑架构设计的整体思维便是质疑驱动
结构设计和行为设计相分离。
架构设计不是一蹴而就。需求对架构设计有“驱动”作用,不断设计中间成果->质疑中间成果->不断调整完善细化中间成果->继续质疑->继续完善…
物理架构思维框架:目标层(XX性),思维层(XX开销,xx争用),结果层(软件单元, 数据单元, 物理节点, 网络)
运行架构:如果系统中没有引入并行处理或者并发处理,并且系统也没有基于sdk,api等基础软件进行定制开发,那就不许要运行架构
运行架构包括:1,控制流(进程线程,中断的服务)2,控制流组织(系统启动停机 控制流通信 加锁或者同步)
确定引入控制流的几点建议:为了实现节点之间的通信,通常的做法是引入一条控制流来专门负责,物理架构中每个节点至少有一个控制流,节点是具有主动行为的设备,并为其引入专门的控制流,来自用户或者外部系统的并发访问,常需要后端服务支持多控制流。在需求一级描述的并发或者并行的也需要引入控制流
一单系统中不止一条控制流,则需要附加工作量(创建 销毁 建立共享内存 消息)等不同工作量直接的通信机制
控制流:是再一个处理机上顺序执行的系列动作。控制流图显示了系统中不同控制流之间的关系,控制流的起点是主动单元,它会调用被动单元,如此层层调用,就形成了一个控制流。明确了系统中所有的主动单元,就抓住了每个控制流的源头,从而可以把并发执行的所有控制流程理清楚。
运行架构设计工作只要把握住控制流图,就能提纲挈领的开着其它设计工作
控制流的常用手段:进程 线程 中断的服务