自已建设网站流程,做僾网站,陕西电商网站建设,电子商务网站建设是学什么最近牵头在梳理部门的系统架构合理性#xff0c;开始工作之前#xff0c;我首先想到的是如何定义架构合理性#xff1f;
从研发的角度来看如果系统上下文清晰、应用架构设计简单、应用拆分合理应该称之为架构合理。
基于以上的定义可以从以下三个方面来梳理评估#xff1…最近牵头在梳理部门的系统架构合理性开始工作之前我首先想到的是如何定义架构合理性
从研发的角度来看如果系统上下文清晰、应用架构设计简单、应用拆分合理应该称之为架构合理。
基于以上的定义可以从以下三个方面来梳理评估
1、系统的上下文清晰明确的知道和周围系统的调用关系数据同步机制
2、应用架构设计简单架构分层合理功能定位清晰不会出现功能边界之外事情
3、应用拆分合理系统内的应用粒度在一个合理的范围内应用间调用链路不应过长。
系统的上下文清晰
系统上下文图一词最早是从Simon Brown的C4模型中借用而来的该模型”通过在不同的抽象层次重新定义方框和虚线来抽象表达架构的含义“。
C4模型把系统分为四层每层都代表着不同的视图架构关注点不同。第一层讲的系统上下文系统高层次的抽象。
如下图显示个人银行账号在浏览账户过程中发生不同的系统之间交互。 如果把Internet Banking Sysytem 当成我们的目标系统那么E-mail System、MarinFrame Banking Sytem 就是它的伴生系统也可以称为外部系统它给Internet Banking Sysytem 提供系统价值属于系统外是黑盒。 系统上下文明确了目标系统和外部系统的关系它和外部系统一起给目标用户提供价值。绘制系统上下文的时候需要注意目标系统和外部系统之间的依赖方向。北向依赖意味着外部系统调用目标系统的服务需要考虑目标系统定义了什么样的服务契约南向依赖意味着目标系统调用了外部系统的的服务需要了解外部系统的接口、调用方式通信机制甚至当外部系统出现故障时目标系统该如何处理。
除了参考以上的画法也可以用业务序列图表示。它脱胎与UML的序列图。序列图可以从左侧的角色开始体现消息传递的次序。这隐含这一种驱动力我们从左侧的参与对象开始寻找与之协作的执行步骤然后层层传进地推导出整个完整的协作流程。
企业序列图代表了企业级系统的抽象目标系统和外部系统之间的协作关系参与的系统是一个完整的整体所以不需要也不应该参与系统的内部实现的细节消息的方向更多的代表系统的责任。业务序列图如下所示 应用架构设计简单
应用本身是有架构分层的Martin Fowler 在《企业应用架构模式》 提出合理的系统分层应该包括表现层领域逻辑层数据源层。 表现层主要提供服务处理用户请求。领域层是处理逻辑是系统的核心。数据源层与数据层、消息系统与其他软件包通信。
后续发展的领域驱动架构设计演变成四层在表现层下加入了应用层同时把数据源层改为基础设施层突破了数据库管理系统的限制。
基于以上的系统分层无论你是采用的三层架构还是四层架构应用代表着功能边界提供那些核心的能力能做那些事情那些事情不能做。
一个好的实践经验是参考领域驱动设计的业务域的方法论梳理好系统的一二三级域最多不超过四级做好各级域的定义。好的域的定义代表着系统能力的边界让你明白那些事情能做那些事情不能做。
基于以上梳理好的系统业务域的定义和能力边界我们在梳理的时候通常会两类系统第一类是现有存量的系统且需求迭代相对频繁的系统这类系统关键是要梳理出有哪些核心的能力是否在上述系统的域的定义范围内的是否其他系统有类似的能力如果有的话需要考虑合并。另外还需要考虑核心能力公开化、文档化至少让部门内知道有地可查避免系统的重复造轮子。
遇到第二类系统是存量系统且没有需求迭代业务上基本没有调用量的。这类系统需要和业务沟通是否有下线计划是否有类似的系统可以替代给业务决策提供技术参考。
应用拆分合理
需求开发中一个项目或者需求的实现可能需要多个目标系统协同来实现这涉及到目标系统的拆分的粒度系统拆分成应用的粒度没有统一标准但是要在相对合理范围内可以参考的因素包括业务规划系统调用量级基于业务规划的架构设计部门内的人数及分工。过多过少都是不好的。
如果一个新业务短期内看不到大的发展在初步规划应用的时候可以先粗粒度拆分部门内人数平均不能应该超过2-3个应用再多必然面临着一个需求实现的时候不同系统的切换成本。如果后续业务发展起来部门内人数增多因为分工更精细可以考虑更细粒度的拆分系统拆分必然会带来另一个问题系统之间该如何的协同以及系统的调用链路的长度。
基于以上讲的系统分层的概念部门内系统可以分为两类一类系统是业务网关一类是通用的业务能力。业务网关面向用户用来协同应用的活动不包含业务逻辑不保留业务对象的状态相当于领域驱动设计应用层表现层有人称作它为业务SOA或者BFF层。
通用业务能力相当于领域逻辑层基础设施层作为软件的核心所在保留了业务对象的状态对业务对象的持久化被委托给基础设施层基础设施层作为其他层的支撑层实现了和其他系统的通信实现业务对象的持久化。
在以上两类系统中业务网关是依赖通用业务能力层业务网关是北向依赖通用业务能力层是南向依赖。 在一个功能的实现不建议链路长度不超过2。同时也要注意到系统之间相互依赖的情况要重视此点是系统稳定性的风险点。
成本量化
基于以上三方面分析梳理出的交付物:1、系统的上下文依赖2、 系统的业务域定义及能力规划地图。3、应用调用链路的长度及相互的依赖关系4、应用拆分粒度合理性的评估5、系统中能力的下沉或者合并6、业务量少的系统列表。
其中1-4可以看作系统的行动指南或者原则5-6是下一步的行动更简单的说是我们常做的系统的关停并转。在业务部门系统关停并转还需要考虑到成本问题做好成本的量化。
首先需要评估关停并转的付出的成本其次要评估系统日常维护1-3年的成本包括人力成本和机器资源的成本前者和后者的三年累计值相减如果大于零系统建议暂时不动如果少于零可以考虑关停并转的计划。
以上是我从研发角度系统架构合理性的思考。
架构合理性如果从业务角度来评估可能就变成以下三个方面一是能解决当下业务需求和问题。2、高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题。3、前瞻性设计: 能在未来一段时间都能以第2种方式满足业务从而不会每次当业务进行演变时导致架构翻天覆地的变化。
视角的不同必然代表着大家对同一件事情的看法不同。 作者京东零售 高田林 来源京东云开发社区 转载请注明来源
