SOA和ESB了解初步

1 引言

就是单纯的做个了解，做个记录，用到的时候再深入研究

SOA-—面向服务架构，实际上强调的是软件的一种架构，一种支撑软件运行的相对稳定的结构，表面含义如此，其实SOA是一种通过服务整合来解决系统集成的一种思想。不是具体的技术，本质上是一种策略、思想。

ESB-—企业服务总线，像一根“聪明”的管道，用来连接各个“愚笨”的节点。为了集成不同系统，不同协议的服务，ESB做了消息的转换解释与路由等工作，让不同的服务互联互通。

SOA的核心思想一直在强调就是要找到可以复用的服务，这些服务满足离散，松耦合，无状态，粗粒度等特点，同时这些服务可以组装和编排，灵活满足业务变更的需要。 使用SOA架构，用ESB提供服务

ESB的工作就是提供和调用集成系统的服务。使用了ESB，在大多情况下，每个系统和ESB之间，只需要定义一个访问方法，一个接口。如果这样，像上图一样，你有8个系统，就会有16个接口（1个方向1个）需要被创建、维护、管理和关注。

如果没有ESB，你就需要56个接口需要去思考和处理。（假设每个系统都需要跟其他系统对话）少了40个接口意味着少花时间和金钱。

解耦中介 ：客户对实际服务提供者的身份、物理位置、传输协议和接口定义都是不知道也不关心的，交互集成代码提取到了业务逻辑之外，由ESB平台进行中央的宣告式定义。ESB平台实现协议转换 (WebService，Http，JMS…)，消息转换 (转换、充实、过滤)，消息路由 (同步/异步、发布/订阅、基于内容路由、分支与聚合…)。
服务中介 ：ESB平台作为中介提供服务交互中的基础服务。ESB平台实现SLA (可靠性保证，负载均衡，流量控制，缓存，事务控制，加密传输)，服务管理监控 (异常处理，服务调用及消息数据记录，系统及服务的状态监控，ESB配置管理)，统一安全管理 (这个有点理想主义)。
服务编排 ：多个服务进行编排形成新的服务。ESB支持一个直观的形式定义新组合服务的流程(工作流、BPEL 或代码级编排)。

自治（理）性 ：服务应该是独立部署和运行存在的，且边界清晰，应尽量减少对外部的引用和依赖。
粗粒度 ：服务调用是需要开销的，这也是实现松耦合的分布式系统必须付出的代价。因此，应尽量通过一次服务调用传输所有需要的数据，而不是分多次去调用服务和组装数据。
可见性 ：服务是对外提供的，必须在某公共的地方可搜寻和发现，且服务要有必要的描述。
无状态 ：服务不应该依赖于其他服务的上下文、会话等，尽量减少不必要的状态管理流程所带来的资源消耗。但是，对于业务流程服务而言，状态数据是不可避免的。
幂等性 ：当消费者调用服务后，服务调用可能会有“成功、失败、超时”这三种状态，当服务并没有最终响应完成时，消费者可以尝试反复地调用服务，这样仍不会影响到最终结果。
可重用性 ：服务应该是可以被重用的，相同功能应可以调用相同的服务，这也是软件设计的原则。
可组合 ：服务是可以被当作成一个步骤的，服务也可以调用其它的服务。这样能够灵活的组合。

SOA与云整合既带来应用和业务流程灵活的虚拟化和节省的费用（云），又带来原有应用的集成应用及业务流程的敏捷重构（SOA）。

上层基于 SOA 进行应用服务的开发，底层基于云计算进行资源整合，包括存储，网络，数据库，服务器等。

目前业界比较多的观点赞同：SOA 与云计算将整合发展。

阿里云云服务总线 CSB为例