SOA架构设计案例分析

　

转载自：https://www.jdon.com/soa.html

首先Martin Fowler提出SOA歧义Service Oriented Ambiguity，认为"什么是SOA"是不可能回答，因为不同的人意味着不同的事情，SOA意味服务接口，意味流程整合，意味资源再利用，意味着管制，在下面SOA组件图中，服务和服务消费者(客户端)之间存在多个约束，当一个服务显式暴露后，客户端能够通过绑定定位到该服务，相当于两者签订了合同，规定了合同内容和如何实施，具体合同的描述是通过消息方式进行：

　　由于Java等传统语言主要是以类表达对象，将功能行为封装在类内部，而业务客户一般都是注重软件的功能，包括同行业公司系统之间数据交流也是以功能服务为接口，因此，面向服务的架构SOA更加贴近业务客户，也更适合业务伙伴之间流程整合，各个行业已经诞生自己行业特点的SOA，例如电信联盟的NGOSS，已经成为电信行业业务支撑系统BOSS的标准。SOA不但是技术用语，也是业务销售用语，通过服务这个中间概念，可以实现业务和技术之间的无缝转换，如今SOA已经和REST DDD以及云计算等新技术方法结合。其内部主要概念有SCA ESB JBI等等，涉及工作流 规则引擎 消息总线等多个技术细节方面。

　　通常，一个架构师进行系统架构顶层设计时，必须考虑使用者的利益，不能单单实现软件的功能，还要考虑到软件的性能Scalable 可用性available/usable 安全性等软件质量，还要借鉴社区的最佳实践和经验形成的模式和反模式，避免重蹈覆辙和陷阱，再大胆采取最新的软件技术(比如用REST替代SOAP等)。

　　服务的提出其实隐含了两个概念，服务提供者和服务消费者，这两者之间有一个合同约定，这非常类似我们现实生活中签订的服务合同，A单位和B单位分别是服务的提供者和消费者，两者签订了一个服务合同，规定A为B提供某项服务。服务就是提供一些公共需求的设施，通过一个工作过程能提供帮助，使用，让使用者受益。

　　服务具体有如下：Windows Service:如PC定位者RPC Locator, 事件日志EventLog, DHCP Client,；. 软件服务Software Service，如分布式服务Distribution Service, 警告服务Alert Service 安全服务 Security Service, 日志服务；业务服务Business Service，如 帐号和客户服务，销售服务，订单服务，采购服务。

　　服务两个重要特点：自治和管制，自治代表服务不能被外部势力牵制，比如如果一个服务内部处理中需要调用外部资源或等待外部流程结束，这种等待不能影响服务本身的调用，如果一个服务分为显式对外和隐式内部两个部分，那么自治是针对隐式内部，意味着我们不能在具体一个服务中直接使用同步代码实现复杂功能。如：

public AServiceImpl implements AService{

　　public void productSale(...){

　　　　Product product = productService.getProduct();
　　　　int inventory = InventoryService.getInventory(product);
　　　　int price = priceService.getPrice(product);

　　}

}

　　在AServiceImpl的productSale方法中，我们获得商品的库存和定价，都是通过同步的RPC实现调用的，这样造成productSale方法依赖于InventoryService和priceService，无法实现自身自治。

　　实现服务真正自治，实际就是解决类之间依赖耦合的问题，消息是一种方式，但是基于消息又有两种通讯方式，基于请求响应和基于事件的EDA。

　　从服务自治可以看出，为什么要提出服务必须自治，因为服务是受管制的，在实际业务活动中，不同服务是被不同部分管理，比如定价服务归属财务部门系统，库存归属仓库系统，涉及系统之间调用协调不能自己使用同步RPC，而是需要消息。

　　在实际应用中，很多单位使用SOA主要看中其能够无缝整合新旧系统,称为EAI企业应用整合，下图是苏宁的一种SOA图，使用ESB企业服务总线这样的消息系统整合了新旧各种系统。

　　使

用SOA和ESB能够灵活实现业务流程管理，工作流的管理BPM，如下图，一个订单的产生可能需要几个部门批准才能完成，而且这几个部门经常是变化的，如何灵活实现这种批准流程的定制也成为SOA实现的一部分，如下：

　　注意图中1 2 3 4 5 6 7 8 9标注的订单处理流程步骤，这种不同服务之间调用处理顺序可通过BPM进行灵活定制。