可扩展架构介绍

1、系统分析模式

• 面向流程拆分：按照业务流程拆分成几个阶段
• 面向服务拆分：将系统提供的服务拆分
• 面向功能拆分：将系统提供的功能拆分

一般说来，流程>服务>功能。下图是一个简单示例：

2、扩展模式分析   

   做好架构，系统在实际工作时才好按照团队设计好工作分解、用人所长；架构清楚方便进行开发和维护；结构清晰才好方便部署。仅就可扩展性来说，架构清晰的才会真正做到高内聚、低耦合，修改和封装才能有效开展。

类型	说明	可扩展架构	使用场合
面向流程	修改时只要修改某一层	分层架构	针对大系统
面向服务	服务扩展时只要扩对应服务	SOA、微服务	针对系统内子系统或服务
面向功能	扩展对应的功能	微内核架构	内部的功能分解

3、分层架构

一般是2~5层，最常用的是3层架构。

• C/S机构、B/S架构。
• MVC架构、MVP架构
• 逻辑分层架构。大系统的架构师，上来就是一张逻辑分层的技术架构图，往往来上很多层。比如：基础设施层、数据接入层、资源整合层、公共服务支撑层、应用层、展示层等等，不一而足。往往是画个很漂亮的大图，一堆属于把人整晕，实际改怎么干根本没概念。分层架构的设计上，一般每层上、下会有一个虚拟接口层，屏蔽掉外部接口复杂性。缺点也明显，就是层层传递，效率会降低，架构上有些重。不过在目前

不管怎么分层，关键不是图好不好看，而是逻辑要清晰。高内聚、低耦合。层级之间差异足够清晰、边界足够明显，便于理解和实施。确实一张好的图，比100页文档好；一张混乱的美图，只会把事情搞得更糟。

4、SOA架构

SOA 出现 的背景是企业内部的 IT 系统重复建设且效率低，主要表现在：1、企业已有各种信息系统，多有重复交叠内容；2、

采购自不同供应商，实现技术不同，企业自己也不太可能基于这些系统进行重构；3、随着业务的发展，复杂度越来越高，更多的流程和业务需要多个 IT 系统合作完成。SOA提出了3个重要概念：服务、ESB、松耦合。

SOA架构是比较高级的架构设计理念，一般情况下我们可以说某个企业采用了SOA架构来构建IT系统，但不会说某个独立的业务系统采用了SOA的架构。SOA解决了传统IT系统重复建设和扩展效率低问题，但其本身也引入了更多的复杂性。ESB是厚重的，ESB需要实现与各种系统间的协议转换，数据转换，透明的动态路由等功能。ESB本身也会成为整个系统的性能瓶颈。

 SOA与微服务架构比较：

          随着互联网信息爆炸的时代，传统的架构已无法支撑互联网应用，互联网应用特点：高并发，可扩展，可伸缩，高可用，敏捷，安全等特点。随着而来微服务框架Dubbo，SpringCloud来势凶猛。尤其是近两年SpringCloud发展迅猛。提供了一系列全家桶开发框架。服务治理、服务注册、服务发现、客户端负载均衡、API网关、监控等功能。

简单来说：

SOA是把多个系统整合，是集成的思想，是解决服务孤岛打通链条，是无奈之举。一般传统企业已经有大量信息系统投资，不可能重新分拆、重构、设计，企业领导不会有精力和想法全部推倒重来,只好用ESB来交换集成，使用webservice 以及soap这种基于xml的技术。ESB集中化的管理带来了性能不佳，厚重等问题，但传统企业IT追求的是"需求灵活,变更快"，这个问题没有那么突出。

而互联网企业通常比较年轻, 没有那么多异构系统, 业务一般也比较单一。如果有整合或者服务化的需求，重构也比较简单，当然还有我在前面博文不断强调的，现在的互联网基础设施（云计算、宽带网络、大容量存储等这些基础资源的丰富和价格相对低廉，而人工成本突出）发展有关。

SOA提出时候更多还是一个概念, 而不是成熟的具体实践。 现在的微服务 , 相比ESB，其实更像是 SOA 思想的一个更好的具体落地模式。ESB这种笨重的中心化产品确实不适应这个时代了。