从开始进入软件行业，到走到今天，也见识过很多项目，就简单对于系统架构中服务层的设计做个总结吧

1.烟囱式开发模型
早期是这种模型居多，WEB-SERVICE-DAO，在一个项目中从头到底，A业务会对B-SERVICE有一些业务上操作，C业务也可能对B-SERVICE上有一些操作，对于一些基础性的东西通过提取工具包提供给各个业务线依赖使用。
这种情况就是说不同应用共性的东西是散落到不同WEB应用中，那么可以很清晰的看出，这种架构是非常脆弱和僵硬的，因为若是稍微对其中的一个SRVRICE业务作出修改，那么所有有过对于这个SERVICE的依赖都需要改动并上线。这种架构应该说很常见，Martin Fowler称之为事务脚本式的开发方式，为了解决这个问题，就出现了以下方式。

2.共性SERVICE的抽取，并以远程访问的方式提供。
到这步的时候已经算是迈了一小步，但是在实际操作过程中缺出现了一些混乱，对于共性service，没有做很好的分层架构，也就是说一个应用自身的WEB和自身对外暴露的服务都去依赖了一个公共的服务，若是业务线少的情况下还好说，但是若是一多的，那么整个依赖体系就会非常的复杂和混乱，虽然不会出现循环依赖，但是对于开发人员来说还是非常的痛苦

3.服务的分层
走到这步的话，大致上将系统分为表现层、服务层、服务组件层、基础组件层、持久层。
3.1 表现层：主要解决数据的展示，接受外部的请求，并根据请求的类型选择不同的服务层，根据服务层的返回结果选择合适的页面进行展示
3.2 服务层：这层是架构设计中最为关键的一层，需要区分是哪些是这个业务个性的业务和共性的业务，将个性的业务放入在这层。
3.3 服务组件层：故名思议，它应该只是一个单纯的服务数据提供，不能含有业务线的具体业务含义
3.4 基础组件层：这里常见的就是DAL，对于底层持久化方式的封装，当然还有其他种种，例如缓存，数据的路由等等
3.5 持久层：是对于不同持久化的封装，后面可能是文件，可能是关系数据库，或是NOSQL等等

个人理想中的SOA架构应该是如上的，但是从各处获得的信息，很少有公司能做到如上的分层架构，包括自己现在所在的公司，也包括聚划算，美丽说之类！它们更多的是将服务层和服务组件进行了合并，是一种简化版本的SOA架构，带来的问题就会有很多，还是先说说上面这种架构设计的优点吧。

4.优点
1.良好的分层中，在不同层级中能够屏蔽自身的实现细节，上层不需要关心下层的具体实现。专业的术语就是可用性提高了。
2.接口化的分层加上依赖导致原则的结合使用，能够方便实现下层的无缝替换，还是用专业的术语总结，可维护性强了！
3.良好的分层后，上层可以在下层基础上搭建出属于自己的应用，一个很典型的例子就是TCP/IP的分层：
TCP/IP是将整个网络分层了 网络接入层，网络层、传输层、应用层，上层构建于下层之上，TCP协议就是位于传输层中，那么构建于其上就有HTTP,FTP.SSH等应用层。专业的术语总结就是标准化后能够更好的构建上层服务！
4.灵活伸缩扩展，之前烟囱式调用在扩展的话，若只想扩展service，那么不可避免的会扩展了web，其实我们的web完全能够撑住流量的增长，如此造成资源的浪费，按照SOA的这种架构就能很好的避免这个问题，用句专业的术语就是 可扩展性更好了！

5.问题
到现在再回过头来看看将服务层和服务组件层合并后的问题，服务组件层暴露是一个粗粒度的服务，然后在各个业务的服务层将这种粗粒度的数据转化为针对各自业务细粒度的接口，那么若是将这种粗细粒度的分割层次进行合并，那么必然导致的就是在将来业务扩展时无法良好的服用基础组件。

再说的直白点吧，一个个性化的服务污染了单纯的服务组件层，带来问题是在面临一个新的业务出现时，需要开发相当冗余的代码，同时这部分冗余代码会导致将来变动扩散到各个未知的代码中，无法消除冗余代码。

举个例子说：一个商户的组件服务，应该只提供商户的基本信息，不应该暴露在什么：查询在XX日期之前的商户数据之类的服务。这类查询限制条件应该是在服务层该干的事情。如此，这个组件就是非常单纯了，将来其他业务比如：在XX日期之后 之类的需求接入，组件层不需要改动，只需要新增一个服务层即可，而且这个服务层是特性的也基本不会被复用，能够很好的避免代码的冗余问题。

当然，过分的分层也会带来问题，在《系统设计 -- 分层》中也提到过，各个层都会封装自己的数据类型，那么就会存在一个数据格式转化的过程，另一个缺点就是过多的分层会影响性能。虽然有以上两个缺点，个人认为，分为服务层和服务组件层带来的优点还是能够弥补这些缺点的！