欢迎您光临本站,如有问题请及时联系我们。

架构分类是怎样的?

  架构可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构,.

  业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。

  熟悉业务,形成业务架构,根据业务架构,做出相应的应用架构,最后技术架构落地实施。

  如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题。

  一、业务架构(俯视架构):

  包括业务规划,业务模块、业务流程,对整个系统的业务进行拆分,对领域模型进行设计,把现实的业务转化成抽象对象。

  没有最优的架构,只有最合适的架构,一切系统设计原则都要以解决业务问题为最终目标,脱离实际业务的技术情怀架构往往会给系统带入大坑,任何不基于业务做异想天开的架构都是耍流氓。

  所有问题的前提要搞清楚我们今天面临的业务量有多大,增长走势是什么样,而且解决高并发的过程,一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

  二、应用架构(剖面架构,也叫逻辑架构图):

  硬件到应用的抽象,包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

  类似:

  应用架构:应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。

  应用架构图关键有2点:

  1、职责划分: 明确应用(各个逻辑模块或者子系统)边界

  1)逻辑分层

  2)子系统、模块定义。

  3)关键类。

  2、职责之间的协作:

  1)接口协议:应用对外输出的接口。

  2)协作关系:应用之间的调用关系。

  应用分层有两种方式:

  一种是水平分(横向),按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。

  另一种是垂直分(纵向),按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。

  应用的合反映应用之间如何协作,共同完成复杂的业务case,主要体现在应用之间的通讯机制和数据格式,通讯机制可以是同步调用/异步消息/共享DB访问等,数据格式可以是文本/XML/JSON/二进制等。

  应用的分偏向于业务,反映业务架构,应用的合偏向于技术,影响技术架构。分降低了业务复杂度,系统更有序,合增加了技术复杂度,系统更无序。

  应用架构的本质是通过系统拆分,平衡业务和技术复杂性,保证系统形散神不散。

  系统采用什么样的应用架构,受业务复杂性影响,包括企业发展阶段和业务特点;同时受技术复杂性影响,包括IT技术发展阶段和内部技术人员水平。业务复杂性(包括业务量大)必然带来技术复杂性,应用架构目标是解决业务复杂性的同时,避免技术太复杂,确保业务架构落地。

  E8运维是国内最早成立的IT运维技术社区,致力于为运维相关领域的工程师打造一个良好的学习交流平台。深度剖析国内运维业内动态,分享DevOps、自动化运维、智能运维等优秀实践,帮助运维人员提升技能和规划职业发展路线。


来源:本文由E8运维原创撰写,欢迎分享本文,转载请保留出处和链接!