架构设计_阿里弃用dubbo后新框架_架构设计原则(5)

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

2015-10月更新，架构思考

组件划分和服务接口

组件化开发思路在很早以前就已经提出，只是当时的组件间交互更多的谈接口而非服务，同时也没太关心单个组件本身的全生命周期管理。谈组件的时候一定不要先谈开发和技术框架，而是真正从业务架构和应用架构出发去考虑整个业务系统的组件划分，其中包括了业务组件和技术组件，各自应该暴露业务和技术服务能力。业务能力组件化和组件能力服务化也是一直强调的SOA核心思想。

在组件划分清楚后，需要优先考虑组件间的交互而需要暴露出来的服务接口，即组件之间只能通过服务进行协同以进一步实现组件间的松耦合。其次才是考虑单个组件在实现的时候，结合分层开发技术框架涉及到分层，在这里可以进一步参考领域模型驱动和设计的思路，否则很容易实现为表驱动功能而不关心领域模型设计和领域逻辑的实现，即虽然技术框架分层了但是职责不清，逻辑混乱并多处实现。

组件内部的实现一个重点就是应用层和领域层之间的关系，即在应用和领域层之间增加了一个服务层，服务层重点是服务接口和服务的组合等工作，而具体业务规则和数据处理的逻辑在仓储类和规则类里面来实现。注意对于组件内部应用层和领域层交互的服务并不一定要做为分布式的Service服务，也可以直接使用内部的API服务接口即可。将服务层服务接口具体的逻辑实现分离的一个重点就是在后期很容易将服务接口发布为一个供其它组件远程调用的服务方法。

开源组件和技术

对于单一的技术往往很难满足互联网业务场景下不同的功能需求和非功能性需求，对于不同的功能或技术实现往往都需要选择大量的开源组件或技术进行集成。但是这些独立的技术组件如何集成为一个高效的整体就变得相当重要。任何技术的选择都必须为了业务需求服务，模式分析是选择技术的一个重点，即在什么样的业务场景下，面对什么问题我们究竟应该选择什么样的开源技术来实现最合适。

首先是开发技术框架层面的，即常说的基于MVC模式的多层框架，用的最多的估计还是SSH框架，其中在层面又有Hibernate或iBatis多种实现，在控制层本身又有struts和spring mvc多种实现。在展现层相关的技术点更多，包括了一些前端基于javascript和jquery的框架引入，Ajax实现，包括当前互联网各种前端响应式框架，Html5技术等。技术框架的选择看似和业务无关，但是却需要进行业务场景分析，包括当前开发的应用是否需要同时支撑web端和移动app端，是否存在和外部集成和服务接口暴露，在业务交互和易用性层面有哪些要求，这些都需要考虑进去。

其次是实现核心技术能力的技术组件，其中包括了缓存，消息，流程引擎，搜索，安全，任务，日志等诸多内容，这些当前往往都有现成比较成熟的开源技术来实现。如通过memcached或redis来实现缓存，通过rabbitMQ或zeroMQ来实现消息和事件管理，基于lucence的全文检索引擎，开源的ETL技术实现数据集成，开源的jbpm流程集成等。在选择这些技术的时候要注意和前面整体技术框架的集成，技术组件应该保持其高内聚和独立性，仅仅技术组件的能力通过服务暴露出去实现和上层应用的集成。要做到这一点往往就需要对开源组件进一步进行封装和定制，以和技术框架形成一个完整的整体，同时又不要把底层技术组件的复杂度暴露给业务功能的开发过程中。还有就是互联网应用还涉及到外部技术服务能力的引入，如外部的邮件通知服务能力，地图能力，支付能力，各个外部开放平台开发的各种内容提供服务能力引入等。对于外部服务能力的引入建议是要在技术平台层单独进行管理和封装，即在技术能力层有独立和统一的服务代理。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-26396-5.html