SOA架构及其架构分析

一、什么是SOA

SOA即面向服务的架构。分为三层结构：表示层（服务层）、中间业务逻辑层、数据访问层。

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。

它提供了构建系统的标准和方法，可以通过建立组合、复用等服务方法减少业务冗余并通过服务协同合作来加快项目开发的速度。

我们通过网络上的几个小例子来解释一下SOA：

第一个：

假设我要做几道菜：

1.麻婆豆腐

2.素炒小青菜

3.西红柿炒蛋

以前我的做法：
我要做麻婆豆腐，先洗豆腐，然后找到豆瓣酱，把豆瓣酱炸出香味，然后我想到还需要辣椒，我就去切辣椒，切完辣椒放进去后，我发现还需要姜蒜，我去切了姜蒜，然后和烧好的豆瓣酱一起煎出香味，倒入豆腐翻两圈开始焖。
焖好麻婆豆腐之后，我要素炒小青菜。
我立即去洗小青菜，然后烧好油后发现还少了姜蒜，我就去切姜蒜，一阵手忙脚乱，小青菜炒好了。
如此重复进行炒西红柿炒蛋。

有了SOA之后：
先剁好一小碗姜末；再剁好一小碗蒜末；切好青菜，找好豆瓣酱，洗好豆腐，切好西红柿

然后，我想要什么服务，直接取。（这里来说是一个人的SOA）
后来，我为了想提高效率，叫其他人来一起帮忙准备这些材料,后面，有10个朋友来我家，要做的菜式更多了，然后我叫几个朋友一起帮忙准备各种材料。

这里面的思想还可以发散。

我想了一下，再补充一下

对于第一种情况，假设我每种菜要做10份，那么再叫来9个人和我一起重复上面的事情（多个服务器部署同一套系统）
而后面有了SOA,我每一个人就只关注自己的具体逻辑，比如切青菜的专门切青菜，洗青菜的专门洗青菜等等，对于厨师（用户），想要做一份西红柿炒蛋，那他就去拿西红柿和打好的蛋就好了，分工明确，各司其职。

第二个：

统一文字，在秦始皇统一六国之前，各国的文字是不统一的，据说许多常用的文字有十几种写法和读音，妨碍了各国之间的文化交流，就象SOA之前，各种软件平台、各种开发工具和各种接口的组件之间，没有统一的标准，对软件系统之间的整合造成巨大的困难。

因此，伟大的始皇帝统一了六国文字，“书同文、车同轨”就是通过标准解决“复用”和“互操作”等问题。这也为大规模的印刷和文明发展提供了一个良好的基础，这种“统一封装”的文字，对文化交流起到了一个“互操作”的标准作用

二、为什么需要SOA三层架构

SOA的实施具有几个鲜明的基本特征：
粗粒度的服务接口分级，松散耦合，可重用的服务，服务接口设计管理，标准化的服务接口，支持各种消息模式，精确定义的服务契约等。

SOA可以使每个模块独立出来，用什么取什么。即使模块出现问题，也可以用备份模块代替即可。不影响系统的整个运行。每个人的分工也非常明确，各司其职。

三、SOA案例分析

苏宁易购商品详情设计：

商品详情系统介绍

基本介绍

商品详情系统是一个展示商品基本信息、参数等详情的系统，是商品购买的入口。它是电商平台中访问量最大的系统之一，苏宁易购大促期间PV量和UV量很大，这么大的访问量对系统的并发能力要求高。在业务上它与周边系统的关系是高耦合。依赖商品详情系统的的系统特别多，比如：促销系统、推荐系统、大聚惠、等众多营销系统、还有主数据系统、购物车、收藏夹等，业务复杂度高对系统设计提出更多的要求。

业务特点

重点在于数据展示

页面信息丰富，如：商品详情、商家列表、推荐、排行榜等

部分数据时效要求高，如：价格、库存等

业务上依赖的系统多

商品详情系统三要素

1. 展示

产品上需要设计好页面区分展示的内容

技术上主要是页面缓存设计、前端页面模版和JAVA程序的解耦

2. 数据处理

数据全部来源于其它系统，在数据上分为：

基本数据，外部系统传过来直接就可以使用的数据

聚合数据，需要加工才能使用的数据

3. 服务依赖

通过MQ解耦，异构数据

解决好以上三个问题就解决了此系统核心问题。

系统逻辑架构

商品详情系统在设计上分成前、中、后三层结构

前台负责展示，做为VIEW层不处理业务逻辑，负责渲染。

中台负责业务逻辑处理，提供数据给前台，同时还会对外部系统提供服务

后台负责主数据管理，做为数据管理层处理商品主数据、参数、品牌、供应商等，同时部分内容开放给运营进行维护、管理和异常处理等。

前台设计

页面设计：

1. 动静分离

JavaScript、CSS统一放到公共的静态服务器上，完全独立的子域名，防止脏Cookie问题和动态域名中无用Cookie问题，通过文件版本号解决系统新版和旧版本之间冲突问题。

所有图片由独立的分布式图片系统管理，对原图进行不同规格的无损裁减和压缩。

2. 异步加载和懒加载

商品价格、营销活动信息、库存等动态数据通过异步加载

非首屏数据做懒加载处理，提高首屏加载时间，比如评价、商品详情等内容

3. 多级缓存策略

a. 浏览器本地缓存

协商缓存，对于某些时效要求较高的资源通过Last-modified控制数据。做到StatusCode=304

强缓存，JS、CSS等静态资源或者一些页面碎片伪静态数据通过Expires、Cache-Control(http1.1支持)设置做到强缓存，在不强制刷新的情况下可以做到200(from cache)

b. CDN缓存

CDN分两条线有自营CDN和合作商的CDN，图片、静态资源与伪静态数据分

别放在不到的CDN上

c. Varnish缓存

Varnish在设计上负载使用轮询方式，不使用URL HASH策略，用空间换时间的策略， 从而避免热数据问题，也支持横向扩展。

Varnish 缓存和CDN缓存在失效时间错开，从而避免同时失效回源压力过大。

d. 精准缓存

精准缓存失效用于促销活动准时展示的场景，基于Varnish缓存，通过精准控制缓存有效期实现缓存精准失效保证促销活动准时切换。

组件逻辑设计：

商品详情系统中的购买按钮和加入购物车会因商品不同走不同的流程。如：大聚惠商品、定金团商品、预售商品等因促销方式不同，走不同的业务处理流程。促销模式变化多端，可能每个月都会有变化，通常的面向接口编程和加上工厂方法或者依赖管理框架Spring也很难做到真正的解耦，虽然这样做已经符合开闭原则。我们通过观察者模式很好的解决了这个问题。让前端的页面模版和JAVA应用程序之间真正的解耦。

后台设计

商品数据统一处理设计

商品详情系统商品主数据通过MQ消息来源于外部系统，比如：商品基本信息、参数、参数模版、品牌、品类等。我们设计时把共性抽出来分成三部分：

接受MQ消息并持久化通过Listener

解析报文

业务处理上简化为add、update、delete三个动作

异常组件以观察者模式实现，记录处理失败的MQ消息并对消息进行截取，并供下次再反向执行(一条MQ消息中会有一到多条参数、品牌，所以这里用截取)