P2P平台架构基于组件化架构设计

首先对上图做一个解释：

在组件化架构设计中，需要遵循如下一些原则，这些原则有些属于传统分层架构设计中的原则：

web层调用服务器代理进入逻辑层，逻辑层调用持久层，不应该出现逆向调用。

业务组件间的调用，或说跨模块的调用需要通过服务组件暴露的服务接口进行，跨模块调用建议尽量是同层调用为主，即A模块的逻辑层只能调用B模块的逻辑层，而不能调用B模块的数据层。如果存在对B模块数据层的调用应该转化为B模块的业务服务后暴露到逻辑层。

对于数据库也需要考虑隔离和解耦，为了达到这点，尽量减少对数据库存储过程和关联视图的使用，数据库基本不承载任何的业务规则和逻辑。对数据库中的公用基础数据剥离到公用业务组件中。

对于系统管理，组织，权限，流程等转化为独立的平台层基础组件，为各个业务组件都需要依赖的组件。基础平台层能力如权限，安全，流程，日志等一定要抽取为公用的独立基础组件，业务组件不在承担这部分内容。

不一定要引入复杂的ESB，但是系统内部基于IOC或OSGI模式来实现总线式集成和组件热插拔。

各层提供的服务存在分级，数据层提供数据服务，逻辑层提供业务服务，UI层提供UI组件服务。平台层提供基础的技术服务和流程服务等。

如果在DDD领域驱动架构设计下，数据层转化为基础架构层，业务层转化为领域层，整体思路仍然不变。而领域驱动设计中的应用层转化为组件集成和整合层。

将跨系统的流程整合的概念引入到系统内部，各个业务组件即可以理解为独立的子系统，可以考虑这些子系统间如何通过服务组装和集成解决流程整合的问题，但是并不一定要用到BPEL。

在这种原则下，业务组件之间本身也不存在交叉依赖，业务组件之间的依赖关系是一种多层传递关系，如A组件依赖B组件，B组件依赖C组件。对于整个组件依赖关系建议是一种倒金字塔的结构，这样可以实现最大化的组件独立部署。

组件化技术架构

前面已经对组件化技术架构做了一定的描述，在此再进行一些关键点的说明。首先对于企业级的应用系统开发建议还是采用标准的MVC模式。对于SSH框架在做一点说明是，对于ORM数据持久化，可以考虑使用Hibernate还是轻量灵活一点的iBatis来做。对于struts和spring没有过多的说明，struts考虑尽量多使用标签库或对标签库进行模板化定义。对于Web展现层框架，可以考虑使用jQuery来或其它来做。

传统Web展现层，不管是jsp页面还是html较难以实现Web展现层的独立打包和组件化管理。这也是Web展现层引入sitemesh框架的一个重要意义。

对于软总线这块，其实Spring和IOC机制已经实现了内部的一种软总线，软总线重点是负责组件，接口的注册，寻找，装载，调用等机制。在内部软总线这块，需要考虑是否引入OSGI软总线，类总线重点解决是内部类接口的反射调用问题，偏白盒层面。而OSGI软总线解决的是组件的独立建设，部署，管理和升级的问题，偏黑盒层面。OSGI软总线将更容易从物理逻辑层面来体现组件化架构和组件热插拔的概念。

对于SOA架构，其核心还是在于组件化和服务化，然后才是服务管控和治理，基于服务化思想对传统软件开发生命周期过程的改进。SOA架构大家刚接触时候很容易将其理解为一种单纯的技术架构，或者更多的人仅仅是将SOA理解为service服务接口，这些都是对SOA方法论很大的误解。

SOA技术架构不要考虑的太复杂，其本质仍然是组件化和领域服务设计思想下，可复用组件设计，服务接口的设计这些传统软件架构设计的内容。目的就是首先要解耦，其次才是解耦后的组件能够快速的装配。这些思想没有理解而一下进入到单个服务识别或接口的设计，那就很难从全局来掌握整个SOA架构的合理性。

通信框架如下：