【架构师】应用架构详解

https://blog.csdn.net/ejinxian/article/details/78150142

 

https://baijiahao.baidu.com/s?id=1609601203210722101&wfr=spider&for=pc

 

https://blog.csdn.net/boonya/article/details/51376451

 

应用架构:

  1. 拆分业务架构,定义应用边界,决定了系统有哪些应用,以及应用之间的分工合作。应用就是子系统和逻辑模块。

 

https://blog.csdn.net/jxguoyan/article/details/8807964

  1. 应用架构:主要考虑部署,例如你不同的应用如何分别部署,如何支持灵活扩展、大并发量、安全性等,需要画出物理网络部署图。按照应用进行划分的话,还需要考虑是否支持分布式SOA

应用架构图关键有2点:

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

1)逻辑分层

2)子系统、模块定义。

https://blog.csdn.net/zhuoxiuwu/article/details/80285953

子系统与系统的定义一样,只是观察的角度有差异,一个系统可能是另一个更大系统的子系统。比如微信本身是一个系统,包含聊天、朋友圈、支付等系统,而朋友圈系统又包含评论、动态等模块。

3)关键类。

2、职责之间的协作:

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

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

应用分层有两种方式:

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

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

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

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

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

 

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

 

典型的应用架构:

https://blog.csdn.net/mn_kw/article/details/72651984

mvc,rpc,soa,微服务

 

===========================

本篇是对应用架构的一个总结

发布了27 篇原创文章 · 获赞 8 · 访问量 2万+

猜你喜欢

转载自blog.csdn.net/fox3012/article/details/82635038