某工业企业公共服务平台架构设计

现在的位置: 首页 > 综合 > 正文

某工业企业公共服务平台架构设计

2013年09月15日 ⁄ 综合 ⁄ 共 8789字 ⁄ 字号小中大 ⁄ 评论关闭

平台背景

XXXXXXXX平台需依托现有
IT系统及未来信息系统建设的要求，规划部署公共服务及基础计算资源，要求对现有业务系统平台进行全面的统一规划和翔实的梳理，建立高可用性、高性能的业务服务载体，提供不间断的业务统筹水平和实施监管能力，符合现代
IT
建设运维要求。

系统多样化，采用技术平台也有其多样性，既有集中控管的业务系统，也有分布式运营的生产系统，从技术层面来看，存在多种异构应用服务，异构数据平台等多种计算资源。硬件层面涵盖了多中操作系统及主机环境的服务器和存储系统，网络交换及路由分布涉及到多种网络设备及核心汇聚。

新的公共服务平台应该是一个具备高可用性的业务环境，这种高可用表现在业务运行的高可用性，而非单一的数据库层面或服务器系统的高可用性。

新的公共服务平台应该是一个具备高性能的业务环境，这种高性能不但体现在业务响应时间和业务处理的速度，还体现在对业务并发控制及数据吞吐量的性能保障。

新的公共服务平台应该是一个具备松耦合架构的可扩展的技术平台，该平台可以提供统一的标准来保障异构系统的读取接口和其他业务横联及流程系统所需的开放协议，此架构易于实现，原有业务系统改造可在此架构上实现平滑的重构，降低系统迁移的风险。

新的公共服务平台应该是一个安全的、易于管理的、符合ITIL
运维建设思路的服务管理平台。

总体思路

基于以上背景和技术要求，架构设计的总体思路如下：

由于这是一个新建系统且必须严格的考量其业务的高可用性、高性能，因此从设计之初务必考虑其系统载体所提供的服务类型及特征，比如此公共服务平台上运行的系统属于哪种性质的
IT系统，是计算密集型还是服务流转型，是高集中高频率的数据处理吞吐型还是并发访问控制型，是计算资源安全重于效率型还是为保证效率平衡系统瓶颈型，是总线服务入网即用的
ESB
类型还是面向服务流程保证高度统一的
SOA
类型，是分布式集中控管的私有云类型还是多层次的集中服务分发类型。根据这些我们有必要编制一个企业
IT
业务系统调查表并请用户方及系统实施方配合填写。

当我们确认了系统类型后，结合业务情况，比如考虑应用吞吐量、分发HTTP
请求数量、
session
持久性、数据处理形式（逻辑读写、查询）等确认系统的初始架构，并以业务系统数据流为轴线，划分每一个层次的架构分布，结合容量管理充分考虑硬件及服务器存储数量和负载均衡的模式。

涉及到数据库层面的东西我们还是要结合业务的特征，来确认在保证高可用、高性能的条件下，如何进行数据库的环境架构设计，是使用多库横联形成DW
便于使用
cube
查询并将其用于
BI
等业务，还是使用多实例同步方式保证性能和高可用，还是使用单实例多节点方式来保证性能，以上方式各有适合的方面，需要我们审时度势来分别考量。

技术架构思路

本小节旨在描述技术架构，不涉及任何厂商产品配置，您可以使用任何厂商的产品来配置此技术架构的搭建。本技术架构适用用于目前的主流厂商和开源厂商产品。并已经过实际项目的论证。

业务的高可用性这一点上，我们以
2点设计来实现这个要求。

1、
我们将数据流向作为轴线，划分了几个层次，对每个层次中的应用服务提供HA/LB
的集群设计，用以避免单服务的单点故障，并在集群设计的时候考虑故障切换和负载均衡的设计属性，包括链接上级服务和下级服务的链路均衡并采用适合的链接方式，如采用
JDBC/OCI POOL
方式及含有
LB/HA
特性的连接字符串
XE
的驱动模式。

2、
我们从整个系统来看，对于业务流程，如HTTP
分发过程中，静态页面及
J2EE MDB
的
SESSION
会话、
Spring Framework
中涉及到的数据持久化设计中对于
HTTP
会话性能和应用服务器处理时的路由过程是不一样的，在前端页面中及时采用了
JSON
或其他
AJAX
方式的页面对于
webcache
的处理产生了业务响应速度的不同影响，因此在整个横向的轴线上，我们有必要对进入
HTTP
服务的数据进行
cache
的缓存设计，用以保证
HTTP
的高可用。对于应用服务层面，如何涉及到异步数据传输的层面的东西，为了考虑更好的可用性和可靠性，必要将
JMS
服务作单独的冗余设计，同理，如果业务系统中发现应用服务中涉及到的流程
BPEL
的服务占有率很高，那么单一的设计应用服务器的冗余和负载均衡已经无法解决业务流程上的可靠性了，那么有必要对流程曾面上的
BPEL
的处理进行冗余设计了，再进一步来看，如果这些应用层面的服务还涉及到了流程集成和页面集成是否还需要对异步响应发布订阅、页面集成等技术要点进行冗余设计都值得大家考虑。

业务的高性能这一点，首先不能为了性能而设计性能拓扑。这一点对于复杂系统设计来说不具备好的耦合度，很容易和可用性设计产生重复投资。架构产生冗余。因此最好的性能设计在设计高可用的时候架构已经考虑了性能的规划，如缓存服务的设计，集群设计等。

松耦合和高度开放的可扩展性是以架构设计之初就需要拿捏的，松耦合需要进行设计上的迭代和测试，优化才能满足。实践是检验耦合度的唯一标准，再次不作赘述。可扩展性这一点对于不符合标准规范的私有协议，我们设计的时候一概不采用，不考虑，必要有开源组件的兼容和替换使用，其次使用有标准支持规范的设计模式，最后使用具备API
接口调用的架构组件。以上三点保障可扩展性的成功实施。

易于管理监控维护是架构设计的必备考虑，标准化后的组件、流程、服务均有对应的管理方法、工具来维护，因此松耦合可扩展成为了易于管理维护的基础。

以上架构图是一个典型的应用数据流的系统流程图，我们可以看到这些标注了数字的部分所需的高可用性方式，一般来说我们可以从技术上考虑以下
cluster模式：

第一种模式（如图左所示）也称为 “
青铜拓扑
”
。这种模式包含一个应用程序服务器集群，其中，形成系统集成总线（
SIBus
）的
WebSphere Process Server
业务应用程序、
CEI
和
BPC Explorer
等支持应用程序、以及托管消息传递引擎（
ME
）的消息传递基础设施全部驻留在构成集群的每个应用程序服务器中。

青铜拓扑适合这样的解决方案：只包含同步 web
服务和同步
SCA
调用，最好只有短期运行流。

第二种模式（如图中所示）也称为 “
白银拓扑
”
。这种模式拥有两个集群：第一个集群包含
WebSphere Process Server
业务应用程序和支持应用程序，第二个集群包含消息传递基础设施。

白银拓扑适合这样的解决方案：使用长期运行流程，但不需要 CEI
、消息排序、异步延迟响应、
JMS
或
MQ
绑定、以及消息排序机制。

第三种模式（如图右所示）也称为 “
黄金拓扑
”
。与前面的模式不同，支持应用程序被分隔到第三个集群中。

黄金拓扑适合其余的所有情况，其中，异步处理在解决方案中发挥举足轻重的作用。这种拓扑还为应该在这种环境中运行的业务流程应用程序提供大部分 JVM
空间。如果可用硬件资源允许设置一个黄金拓扑，建议使用这种拓扑模式从头开始，因为它是用途最广的拓扑。

构建
cache服务非常有必要，有效的网络
Cache
系统可以大大地减少网络流量、降低响应延时以及服务器的负载。但是，若
Cache
服务器超载而不能及时地处理请求，反而会增加响应延时。所以，
Cache
服务的可伸缩性很重要，当系统负载不断增长时，整个系统能被扩展来提高
Cache
服务的处理能力。尤其，在主干上的
Cache
服务可能需要几个
Gbps
的吞吐率，单台服务器（如
SUN
目前最高端的
Enterprise 10000
服务器）远不能达到这个吞吐率。可见，通过
PC
服务器集群实现可伸缩
Cache
服务是很有效的方法，也是性能价格比最高的方法。

基于LVS
可伸缩
Cache
集群的体系结构如图
2.3
所示：在前端是一个负载调度器，一般采用
IP
负载均衡技术来获得整个系统的高吞吐率；在第二层是
Cache
服务器池，一般
Cache
服务器放置在接近主干
Internet
连接处，它们可以分布在不同的网络中。调度器可以有多个，放在离客户接近的地方，可实现透明的
Cache
服务。

Cache服务器采用本地硬盘来存储可缓存的对象，因为存储可缓存的对象是写操作，且占有一定的比例，通过本地硬盘可以提高
I/O
的访问速度。
Cache
服务器间有专用的多播通道，通过
ICP
协议（
Internet Cache Protocol
）来交互信息。当一台
Cache
服务器在本地硬盘中未命中当前请求时，它可以通过
ICP
查询其他
Cache
服务器是否有请求对象的副本，若存在，则从邻近的
Cache
服务器取该对象的副本，这样可以进一步提高
Cache
服务的命中率。

对于是否有必要对于系统采用
SOA化，我们首先来归纳一下目前的
SOA
优点、缺点，如下表：

表 1.
优点、缺点、糟糕之处

SOA 的良好业务影响	SOA 的不良业务影响	SOA 糟糕的业务影响
敏捷性- SOA 支持更加快速地开发业务流程以及更加轻松地对业务流程进行改变。它可以使组织更迅速地适应他们业务环境的改变。这就转化成为实际的市场优势，因为它能够使产品和服务比竞争对手更快速地推向市场。	组织结构的改变- 在每个 SOA 的中心都有一个卓越中心（ COE ）。 COE 就是一个控制 SOA 技术开发以及向组织的其他人员提供专业知识的新实体。 SOA COE 是对任何组织来说都是新增加的，并且由此推出，当它实力雄厚并且在这里所做的决定会影响组织的其他人员时，它的引入可能会导致冲突。	转变并不容易- 转化和组织成为以服务为中心并不容易。过渡到 SOA 的特点是演变而不是革命。以孤岛的传统形式创建的组织需要改变它们的结构，以充分利用成为以服务为中心的优势。这种转变是复杂的、昂贵的，而且从来不缺少这种变革的反对者。
一致性- 业务与 IT 之间更加紧密的合作关系抛开了阻碍 IT 实现业务需求的传统障碍。业务领域中的服务足迹是一项业务功能，并且用业务术语对其进行了描述。它实现的细节是隐藏的。	组织权力结构的改变将服务的所有权和控制权放到业务领域中，会改变组织中的权力结构。这样做通常会遭遇来自那些有维持现状特权的人的阻力。	文化改变- SOA 不仅仅代表着技术的改变。伴随着这种改革产生了一个组织的文化变革，因为它成为了价值的驱动。组织必须明白敏捷意味着什么以及如何充分开发其自身的敏捷性。糟糕的事实是，这是最难学习的课程之一。
业务流程的改进- 一般而言，任何 SOA 与业务流程的再次思考都是相关的。这种业务流程重构对优化组织运营业务的方式而言是一次机会。良好的重构工作能够使业务的运营效率得到显著提高。	业务面临的新挑战- 业务必须给予 IT 更多的指导。业务线必须对服务及增强行使所有权并对其负责，从而启动开发与变化周期，因为它们将推动这一进程。这不是一种典型的由业务线进行补充的作用，这将会导致不合适的改变。
灵活性- 在 SOA 中坚持良好的软件工程实践能够提高 IT 对业务需求的响应。缩短了产品和服务的上市时间，降低了开发与改变流程的成本。	IT 在变得更简单之前会越来越复杂 - 利用一套如业务流程执行引擎和 ESB 的技术来实现 SOA 。把这种技术添加到 IT 规划中并不会让它更加简单，即使当它的优势远远超过了它的成本。然而， IT 规划更复杂并不意味着它就不能以更简单的形式出现。这种服务的推出让 IT 的复杂性成为秘密。这些服务的消费者不需要知道服务内部是如何运行的。结果，任何发生在后端的的合理化操作，都可以隐藏在服务界面之后。	技术本身不会体现价值- 专注于基础架构和技术的 SOA 是很可能失败的。 SOA 举措是建立在比以往更快速更低成本地提供业务价值的承诺之上的。一种过于重视技术的 SOA 是不可能实现该承诺的，因为它们不会显示出业务人员希望看到的价值。灵活性只有在加速运营性业务需求，或者通过支持业务的合理性来降低操作系统成本时才会被认为是业务价值。以技术为中心的举措一般不会这样做。
数据统一- 服务接口可提供统一数据特征的机会，以使服务接口使用遵照统一的数据模型的数据。统一在这里的意思是通用：结构 - 元素之间的结构关系是相同的，因此例如地址一贯地包含门牌号、街道、城市、地区和邮政编码。语义 - 语义是指含义以及数据的使用。数据必须有统一的含义，并且必须以不会产生歧义的方式使用。例如客户的概念可能会在网站上遇到，与帐户所有者形成对比。格式 - 数据的表现方式很重要。 DDMMYYYY 格式的日期不能与 MMDDYYYY 格式混淆。类型 - 类型是由数据的表现形式以及一套可以执行的行为决定的。时间 - 时间指的是属性更新的时候。在某些情况下属性会在前端系统进行实时更新。然而一些属性只在定期的批处理时进行更新。生命周期 - 在什么情况下将数据添加到数据库中，什么时候进行更新，以及什么时候、以什么方式最终从数据库中删除数据。	没有数据视图- 服务的标准接口需要统一的数据视图。这种统一视图通常不存在，并且设法开发统一视图时往往会发现组织中的视图非常不同。	可能无法实现统一- 使数据的所有特点一致几乎不太可能实现。除了上述问题之外，与 “ 脏数据 ” 相关的问题也总是存在。处理一致性是设计服务接口面临的巨大挑战之一。尴尬的事实是建立统一的服务接口是一件非常困难的事情。
运行监控- 用于支持 SOA 的技术和原理使对业务流程的监控更加轻松。这种监控类型支持来自日常运行的反馈。该反馈可用来衡量组织对其战略目标的实现情况如何。传统的业务流程（BP ）与表现逻辑都写入了包含业务逻辑的相同程序。所能希望的最好结果就是至少将不同逻辑类型组合在一起，但是即使这一点也往往难以实现，其结果是很难监控逻辑范畴。例如业务流程只能作为应用程序的一部分来监控，因为它不能被分离出来。 SOA 通常伴随着业务流程执行引擎。这种技术的引入可促进业务流程逻辑被分配到一个点上。在一个点上拥有 BP 使 BP 监控成为可能，而无需在应用逻辑中使用 BP 逻辑。这不是 SOA 的专有技术，但是用于支持 SOA 与来自 SOA 良好软件工程实践规则的技术能够使该技术在 SOA 中更加轻松地得以实现。	监控复杂性- 开发一个针对组织目标提供反馈的业务流程监控模型是一项需要专业技能的重要工作。
利用操作平台- SOA 使用操作平台为服务提供业务功能。这意味着对现有系统的投资可通过将其重新包装到服务中来使用。	技术不匹配- 在某些情况下并不能轻松地对操作平台进行重新打包，原因是业务功能结构与需求不匹配。例如，如果一个添加新客户的事务在姓名和地址添加到客户数据库之后有一个提交点，并且在安全数据被添加之后有第二个提交点，那么这两种操作将紧密链接。	可能需要做出改变- 在某些情况下可能需要改变操作平台。当需要在 ERP 中作出改变时，供应商非常不情愿做出改变。如果组织决定在内部作出变革，服务资金必须考虑维护成本。

那么我们的系统是不是一个适合做成
ESB企业服务总线形式的系统架构呢？回答是否定的。

ESB 有时被描述为

分布式
基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被
描述为
中心辐射型（hub-and-spoke）
。然而，这并
不是真正的差别。正在研究两个不同的问题：
控制的集中
和
基础架构的分布
。ESB
和中心辐射型（
hub-and-spoke
）解决方案都集中控制配置，比如服务交互的路由、服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更复杂的分布式方式进行部署。毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束
——
有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可能更适合于部署在本地群集中，以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是
ESB
设计的一个重要方面。另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。

如下图：
分布式 ESB
基础架构的集中控制

产品架构思路

基于上的思路，我们按照以下关键字来定义我们的产品架构设计：

产品架构

下图是符合我们的业务系统架构需求的一个产品架构图，该架构图采用的的
Oracle产品线，当然，开源和
IBM
厂商也可以提供此架构的产品，而且性能和价格会更便宜些。我来解释一下这个图：

自顶向下来看，我们防火墙以下首先
web请求需要通过负载均衡设备，此设备可以是硬件的
F5
等设备也可以是例如
IBM
产品中的
websphere edge server
服务，可以将此服务配置成为
HA
模式，第一条虚线表示此层次的
web
负载分发已经完成并很高效了，第二层，这里使用的是
10.1.2
版本的
Oracle web cache
，这就是缓存的作用，在
Websphere
中也有此产品，使用
HA
设计，第二条虚线表示此层将
HTTP
会话进行了分类和静态缓存，提升了性能和高可用，到了第三层，
HTTP SERVER
，这里对应
IBM
的
HTTP SERVER
，提供静态页面解析，缓解应用服务器的压力，并提供反向代理的负载均衡。如果涉及到
OCI
和
proxy
方式的数据库操作，实时性高以及管理维护的需求，包括业务中涉及到数据库的事务
/
回滚段可以
PLSQL
直接操作数据库，否则就将请求交给对应的
servlet
交给相应的
javabean
去出去，这些
bean
可以去进行数据库读写，那么就走
jdbc/jdo
的路径去
oracle rac
，可以去关联某个流程
BPEL
处理
BPLM
的数据，那么就走
process server
去走流程，当然这里的
process server
也可以根据情况设计成
HA
方式，可以去关联某个异步文件传输同步服务，那么就可以管理
JMS
组件，如
MQ
服务，涉及到订阅和发布的就设计为
MESSAGE BROKEN
。应用服务出口可以有安全审计模块，对应
IBM TAM
，
SSO
等组件，无此安全要求的可以去找
DB
，这里的
DB
可以设计为单实例多节点的
ORACLE RAC
形式。如果涉及到多个
RAC
形式可以考虑使用
gird
做，那就是管理层面的问题了。

缓存

大型互联网应用，例如门户网站、在线商城以及联机交易系统等等，往往需要处理大批量、高并发的用户访问请求，这对应用程序的性能提出了比较高的要求。性能问题一般可以在开发和部署两个阶段加以解决。在应用部署阶段，通过增加软硬件投入的方式比较常见，但其费用往往较高；而在软件开发阶段如果能够提前定位并解决性能瓶颈，则会减少大量成本。在开发阶段提升性能，一种常用的思路是降低瓶颈资源、业务模块的访问压力，因而在应用程序中加入缓存机制则因成本低、实现方便等优点成为常见解决方案。

缓存（Cache
）在计算机科学领域指的是一些数据副本的集合。当原始数据访问速度较慢或代价过高时，可以通过使用在高速存储区域中保存原始数据的常用数据副本，从而提升访问速度。常见的硬盘缓存，
CPU
缓存，网页缓存等等都是缓存概念的应用。在企业应用开发时，开发人员也可以基于缓存的概念，使用应用程序级别的缓存，从而来提升应用性能。

常见的开发方式为在 Java
虚拟机里通过
Static
成员变量、
Context
对象或者用户
Session
中，保存常用的业务数据。一旦有访问需求，则先从缓存中尝试获取数据，如果尝试失败，再从实际模块获取数据并更新缓存。

此类方法实现简单，但容易遇到扩展性方面的问题：为了满足业务增长需求，用户可能需要在
多台
主机组成的
集群
中部署应用。此时 JVM
级的缓存会面临服务器间缓存同步的问题，处理不好，会导致数据不一致等严重错误。其他可能的问题还有：

·
应用开发模式的改变：应用程序需要在相关业务处理逻辑处加入缓存相关处理。

·
配置管理：需要在缓存的有效期、大小等方面，如果要求可配置，则需要开发人员一定的工作量来满足此类需求。

针对这些常见问题，IBM WebSphere Application Server
则提供了一套动态缓存框架，能从不同方面加以解决。

IBM WebSphere Application Server 动态缓存机制介绍

动态缓存机制是 WebSphere Application Server
为应用程序开发人员提供的一套扩展服务，其主要功能组件如下图所示：

WebSphere Application Server 动态缓存的主要功能组件

动态缓存机制架构如上图所示。动态缓存机制的核心功能为：在内存中缓存 Java
对象，应用程序可以通过
API
来访问这些对象。为了减少内存消耗，动态缓存服务也采用一些缓存替换机制（例如
LRU-
最近最少使用算法）来实现。对应不同的应用类型，动态缓存机制为应用开发人员提供了不同层面的缓存服务：展示层的
Portlet
和
Servlet
缓存服务和业务层的
WebService
缓存服务、
Java
命令缓存服务和对象缓存服务。

动态缓存服务部署示意图

为多服务器环境下动态缓存机制的部署示意图。应用程序只需通过 API
来调用缓存服务即可，动态缓存服务会

自动
在不同服务器之间根据定义好的策略进行缓存数据同步。当收到应用程序缓存访问请求时，缓存服务会首先在本地缓存中查找相应对象提供服务。一旦被请求的对象位于其他服务器时，动态缓存服务会通过数据复制服务（Data Replication Service, DRS
），来从其他服务上获取相应数据。如果对象在本服务器上有改动，如缓存更新或者缓存删除，动态缓存服务也会通过数据复制服务通知其他服务器。