应用架构：

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

 

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

应用架构图关键有2点：

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

1）逻辑分层

2）子系统、模块定义。


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

3）关键类。

2、职责之间的协作：

1）接口协议：应用对外输出的接口。

2）协作关系：应用之间的调用关系。

应用分层有两种方式：

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

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

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

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

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

 

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

 

典型的应用架构：


mvc，rpc，soa，微服务

 

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

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