企业级PAAS平台-关键问题

　　数据库即服务

　　对于daas首先考虑的是做的厚还是薄，如果做的足够薄，那么daas的核心将重点只关注数据库层实例ID的路由功能。所有sql都进行透传，不做任何的sql解析工作。对于路由规则应该做到可配置。数据库层对应用半透明而非完全透明，通过daas层来实现数据库的软负载均衡。daas层含了数据库即服务，也含了数据即服务。对于数据库持久化层可以下沉到daas层里面，即对hibernate等做进一步的封装。

　　对于mysql集群需要考虑的问题包括。对于master-slave集群，需要考虑的是集群本身的扩展和演进路线。对于读写分离后，第二个层面考虑master库本身的分库，在企业级应用中可以考虑按业务组件进行分库。在分库后需要进一步考虑对于表的水平或垂直shading，这是第二个层面。

　　对于双向复制的mysql集群，需要考虑的是进行shading后的复杂关联查询操作的性能问题。NDB存储引擎性能本身是比innoDB引擎性能弱的。对于NDB引擎下共享内存模式，需要考虑内存本身是否能够足够大支持大数据和大并发的查询操作。

　　中间件即服务

　　这里面有太多的技术点。比较难的包括资源本身的隔离问题，特别是应用虚拟化模式下的资源隔离问题。其次是数据采集模块的性能问题，内部的消息总线的可靠性问题。

　　在动态调度实现过程中，一种模式是基于虚拟机+硬件负载均衡设备的集群模式;一种是应用虚拟化+软集群的实现模式。在大访问大并发的情况下，如果采用软集群需要考虑软集群本身的router节点的性能问题。要知道通过软集群来实现和硬件设备相同的性能和可靠性是很困难的事情。包括负载均衡算法，会话状态的保存，对高并发下的TPS访问量的支持。

　　数据采集模块需要有足够好的实时性，同时又需要对资源本身的消耗最低，这里一般都需要通过较为底层的协议和代码来实现高可靠性和高性能。动态调度虽然有一定的延迟，但是仍然需要一定的实时性保证。强调资源隔离的核心仍然是只有资源隔离的清楚，实时采集到的CPU和内存信息才是可靠和准确的。

　　开发框架和环境

　　企业内私有云的paas平台对开发框架和环境的要求和公有有有较大的区别。但是我们仍然可以看到开发框架需要集成本身的应用系统技术架构，支撑基于SOA模式的组件化开发，对于可复用的组件能够全部嵌入进来方便的使用。对于在线开发和离线开发要同时支撑。

　　开发框架本身是一个实现了底层技术平台和服务两方面集成的内容。对于开发框架和环境的难点还是本身是否能够很好的集成各种组件，设计规范和约束进来。保证各个应用系统遵循相同的开发规范，paas应用接入规范进行开发。支撑一个业务组件很快捷的和外部的技术组件，外部的业务组件进行服务层面的集成和交互。开发框架可轻可重，但是核心能力仍然是组件本身遵循某种技术架构，组件本身遵循标准的服务集成方式和外部交互。

　　应用框架和环境

　　我一直期望做到的就是有一个完全外面的app应用容器，这个应用容器已经包括了登录，认证，统一的权限管理，菜单，系统管理，工作流引擎这些内容在里面。这个应用容器也可以看做是一个没有任何业务功能的空应用。那么这个应用容器本身的难点在于。

　　其一是应用容器本身完全和统一认证，权限，组织人员，用户，工作流引擎进行集成。这些集成不需要各个业务系统或业务组件操心。其二是应用容器如何装载业务组件进来，如何保持业务组件之间的协同和交互。如何管理状态和管理资源的使用等。

　　组织引擎，权限引擎，流程引擎，底层技术组件和平台，4A一系列的事情都应该融合到应用框架和环境里面。因此要开发出这样一个空应用本身就不是一件简单的事情。

　　ESB企业级服务总线

　　在IBM的基于SOA组件化思想里面已经谈到其实一个企业级PAAS应用存在多条总线，包括企业级总线，业务组件间的内部总线，业务组件内部的软总线等。

　　ESB提供统一的服务目录，服务接入和注册，服务鉴权，服务运行，服务监控，服务路由，消息协议转换等功能。不论是soap web service还是restful webservice都需要考虑实现这些内容。在这里问题主要是两种不同serivce模式的采用。按初步理解技术服务适合采用面向资源设计，即rest方式。而对于业务服务，由于对安全性和事务，服务编排都有要求，更加适合soap web service模式。

　　对于业务组件内部的软总线其实是另外一个难点，包括osgi的采用，osgi是否适合大型企业级应用场景，是否存在不稳定的地方，osgi软总线调用模式对性能会构成多大的消耗等。

　　基于SOA的组件化架构

　　组件化架构强调的重点前面已经都谈到过。在基于soa的组件化架构，一方面是强调业务组件间，一方面是强调业务组件内部的类总线osgi模式。业务组件是可以独立进行需求分析，设计，开发，部署和运维的模块。对于组件化架构，我们一直在探索的就是基于t5的web框架模式下的各层彻底组件化。

　　组件高度自治，组件如何进行装载和跨组件协同。组件部署到应用容器后形成可以提供计算能力的计算单元，因此组件本身一定要考虑和paas平台的自动部署和应用托管匹配。符合paas平台的总体接入规范。组件外部遵循统一的接口服务标准，内部又有同样的技术架构。

　　对于基于DDD领域驱动架构来进行组件化架构设计是很好的一条分析设计思路。

　　产品集成和组装

　　真正在业务组件化和组件能力化后，业务系统的概念足够弱化，那么业务组件如何进行组装和集成，完成一个核心的业务功能就更加重要了。业务驱动IT，架构自顶向下形成多个业务组件，识别复用和组件间的接口。而组件在开发完成后又必须进行组件集成，完成一个核心的业务功能。

原文转自：http://www.ltesting.net