转载

谈架构图的构图(6.12)

在做软件或应用解决方案的时候，一定会涉及到总体架构图或应用架构图的绘制，今天就谈下在架构图的绘制时候需要考虑的一些关键内容。

总体架构构图

对于总体架构沟通在类似智慧城市整体解决方案，企业总体IT架构解决方案中用的比较多。即不针对单个业务系统，而是面向整个行业或整个企业的IT整体架构解决方案。在这些图中，一般一个大的业务系统，类似CRM，ERP等也就是一个方框的位置。

这类总体架构重要的一个体现就是分层，一般还是底层的IaaS基础设施资源层，然后是中间的PaaS平台服务层，接着是上层的应用层。注意在当前微服务架构新模式下，上层的应用层本身又会拆分为中台层+上层的应用层。应用层在上面是门户层。

对于PaaS平台服务层，关键的内容还是技术平台，数据平台，集成平台等，技术平台本身又包括了应用托管平台和中间件资源池，传统的4A，流程平台，也包括了各类技术服务的提供。具体PaaS平台服务层要规划哪些内容，可以结合实际的项目需求来进行规划。

如果是对于物联网等项目，那么在资源层下面还有物联网感知层和网络层。

对于应用层，可以考虑对具体的业务系统进行归类或业务域划分，比如企业内的IT架构图，可以基于价值链或其他方式，按市场销售，产品研发，生产制造，客服服务，财务管理等业务域对业务系统进行归类。

对于总体架构图一般两边会规划类似技术标准体系，安全管控体系等相关内容。

注意在总体架构图上，实际上是很难去区分业务应用和BI分析两条线的，建议在画总体架构图的时候，不要去考虑将这两条线都划分清楚。可以在应用层最上面画一个业务决策分析类应用层即可。

基于SOA思想对应用层展开

刚才在讲总体架构的时候没有谈到服务层的概念，那么实际我们在规划总体架构的时候究竟有无服务层，如果规划了服务层我们就需要将关键的业务服务，技术服务等能力画出来。然后将服务能力接入到上层的服务能力开放或共享平台，然后上层的应用基于服务层的能力来进行构建或组装。

即应用的构建是基于服务的灵活组装或编排来构建的，而在微服务架构下，各个中台的中心就是提供给子API接口服务能力，而上次应用可以基于中台中心的能力进行服务组装。

如果我们是画总体架构一般不需要单独画出服务层，但是如果我们是规划总体应用架构，那么就可以将应用层进一步画细，体现出服务层，关键的业务服务和技术服务，体现出共享服务平台。即应用层会再进一步分析，包括了服务层各类服务，服务共享开放平台，然后是上层的应用。

业务服务+服务共享平台+上层应用，即基于SOA思想，基于服务快速灵活构建应用的思想。

单个应用的架构图

首先说应用架构，对于单个应用的应用架构，可以看到单个应用本身往往也分了很多了子系统。比如我们的财务共享应用，本身就包括了报账，预算，资金，电子凭证，档案等多个业务子系统。那么在这种情况下实际上画法首先也是要分层，下面是基础平台层，多个业务系统共用的能力要放到基础平台层，比如我们说的4A，流程引擎，技术平台能力等，然后才是上层的各个业务子系统。这时候每个业务子系统可以将里面的关键业务模块画出来了，体现关键业务能力。上层往往仍然是门户，实现一个统一的集成。

多个业务子系统本身就类似独立的各个微服务模块，因此完全可以采用当前微服务架构的分层思路对架构图进行优化。即技术平台画完后，开始画中台层，中台层即各个关键的业务能力中心，中心层暴露关键的API接口服务能力给上层用，然后才是上层的各个应用。

即技术平台+中台层+服务+应用+门户聚合的架构构图思路。

单个业务系统的架构图

对于单个业务系统的架构图，务必要注意究竟是画应用架构，还是画技术架构。

如果是画应用架构，那么关键要体现的是业务模块和业务功能，因此应用架构沟通的时候更多的分层思路是基础平台层，基础数据层，应用业务功能层，上层的决策分析统计层。当然还可以将该业务系统和外围业务系统的关键接口集成也画出来。

如果是画技术架构，那么参考标准的技术架构图画法即可，比如多层分布式架构，体现数据层，逻辑层，展现层。或是说是基于SOA服务架构，体现的是技术组件，业务组件，服务，上层应用和流程组合。在技术架构图上体现出关键的技术分层和技术组件即可，而不需要体现具体的业务模块和业务功能。

基于以上思考，我们在画架构图的时候关键注意点进一步总结如下

1. 分层是基本指导思想，或者平台+应用，或者平台+服务+应用。

2. 纵向分域分类是第二关键点，否则纵向内容会感觉凌乱，比如平台层可以分技术平台，数据平台等

3. 应用架构和技术架构要区分开，两者的关注点不同

4. 应用架构中对于业务系统和BI类应用要区分开，一个架构图往往也很难体现两者

5. 架构图是偏静态构图，因此在架构图中尽量不要体现流程，交互等内容