SOA 的路究竟要怎么走 ?

feiyang10086

SOA 的路究竟要怎么走 ?

    大家都知道SOA是面向服务的体系结构，是构造分布式系统的应用程序的方法。它将应用程序功能作为服务传送给最终用户或者其他服务。它可解決企业跨平台的問題,是企业跨平台系統的技术解決方案。有了SOA以後，最原始的三层结构发生了变化。很多人在原先的业务逻辑层之上再加一层叫服务层，或者是把业务逻辑层命名了服务层，其目的就是為了提供給UI或者是其它系統的不再是一個类库而是一個服务，這個服務可以跨平台使用。這样的一個出发点是相当好的,也正因为这样一個出发点，很多人喜歡上了SOA，開始SOA的艰辛旅途了。

      開始SOA，很多人或公司首先就会想到需要规范目前公司的开发方法。把原先本來是业务逻辑层的類的方法包裝成一個個服务。于是乎在公司的的开发标准上就多了這樣一條规范。尽量使用WCF或Web Service編寫系統服务提供給其它用戶或UI层使用。這就样每個程序員都开始编写服务了，為公司的SOA架构早点实現而努力。公司为实現這樣一個目标也早在2年前就开始着手一些符合SOA架构理念的中間件(或者说ESB 產品）。可是到目前為止，这些項目都停滯不前。当然这里面有各种各样的原因，如：成熟的真正符合SOA架构理念的產品实在太少 ，真正有SOA架构理念实践经验的人也太少了。沒有经验，所以公司考虑各种风险问题就不敢盲目实施。這些都不是我今天要分享的问题。我要分享的问题是：很多人或公司在准备应用SOA之前沒有作出充分的评估和對以前开发中面临的问题作出充分的观注。

      以前在沒有考虑SOA時，编写起服务來很轻松，觉得无非就是对以前编写的业务逻辑层的方法进行包裝而已。最近在做一个項目的分析和架构设计的时候，由于此系統涉及的关联系统之多，所以想也沒想太多，按原來的方法编写服务就是了。可是到后來当我快完成系統设计的時候。我才发現很多服的功能被重复设计，有的该拆分的沒有拆分，但不該拆分的被拆分了。從而也导致了很多地方使用了服务调用服务，并可能是嵌套了几层，特別是一些本來就需要调用外部服务的功能 。很多人也可能说这样做也沒有什么问题。有些人认为服务应该拆分的越小越好，这样才能达到重用的可能。有些人又觉得嵌套服务這樣的做法会造成严重的系統效能問題，实践也确实证明了这一点。

     这就是所谓的服务粒度問題,服务粒度究竟要怎么來把握？同時各服务之间又怎么实现事务机制，分布式事务真是可行吗。如果是，为什麼如此多人不推荐使用。解决事务问题还有其它解决方案吗？针对这些问题大家又有什么建設性的建议呢，在SOA实施之前，我们要准备些什么呢？在这里希望大家一起探讨，谢谢！

surpass_li

了解。。。