首页 ›存档› 技术 › 查看内容

【深度】微观SOA：服务设计原则及其实践方式（上篇）

2018-3-30 13:00 |来自: 互联网 395 0

摘要: 大量互联网公司都在拥抱SOA和服务化，但业界对SOA的很多讨论都比较偏向高大上。本文试图从稍微不同的角度，以相对接地气的方式来讨论SOA，集中讨论SOA在微观实践层面中的缘起、本质和具体操作方式，另外也用相当篇幅 ...

大量互联网公司都在拥抱SOA和服务化，但业界对SOA的很多讨论都比较偏向高大上。本文试图从稍微不同的角度，以相对接地气的方式来讨论SOA，集中讨论SOA在微观实践层面中的缘起、本质和具体操作方式，另外也用相当篇幅介绍了当今互联网行业中各种流行的远程调用技术等等，比较适合从事实际工作的架构师和程序员来阅读。

为了方便阅读，本话题将分为两篇展现。本文是上篇，着眼于微观SOA的定义，并简单分析其核心原则。

亚马逊CEO杰夫贝佐斯：鲜为人知的SOA大师

由于SOA有相当的难度和门槛，不妨先从一个小故事说起，从中可以管窥一点SOA的大意和作用。

按照亚马逊前著名员工Steve Yegge著名的“酒后吐槽”，2002年左右，CEO贝佐斯就在亚马逊强制推行了以下六个原则（摘自酷壳）：

所有团队的程序模块都要以通过Service Interface 方式将其数据与功能开放出来。
团队间的程序模块的信息通信，都要通过这些接口。
除此之外没有其它的通信方式。其他形式一概不允许：不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等，等等，唯一允许的通信方式只能是能过调用 Service Interface。
任何技术都可以使用。比如：HTTP、Corba、Pubsub、自定义的网络协议、等等，都可以，贝佐斯不管这些。
所有的Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。
不这样做的人会被炒鱿鱼。

据说，亚马逊网站展示一个产品明细的页面，可能要调用200-300个Service，以便生成高度个性化的内容。

Steve还提到：

Amazon已经把文化转变成了“一切以Service第一”为系统架构的公司，今天，这已经成为他们进行所有设计时的基础，包括那些绝不会被外界所知的仅在内部使用的功能。

那时，如果没有被解雇的的恐惧他们一定不会去做。我是说，他们今天仍然怕被解雇，因为这基本上是那儿每天的生活，为那恐怖的海盗头子贝佐斯工作。不过，他们这么做的确是因为他们已经相信Service这就是正确的方向。他们对于SOA的优点和缺点没有疑问，某些缺点还很大，也不疑问。但总的来说，这是正确的，因为，SOA驱动出来的设计会产生出平台（Platform）。

今天，我们都知道亚马逊从世界上最大图书卖场进化为了世界上最成功的云平台……

贝佐斯的六原则展示出高度的远见和超强的信念，即使放到十几年后的今天，依然觉得振聋发聩……想起一句老话：“不谋万世者，不足以谋一时；不谋全局者，不足以谋一隅。”

当然，像贝佐斯这种将神性与魔性集于一身的专横人物，既可能创造划时代的进步，也可能制造前所未有的灾难。

SOA漫谈：宏观与微观

SOA即面向服务架构，是一个特别大的话题。

为了方便讨论，我在此先草率的将SOA分为两个层面（大概模仿宏观和微观经济学，但这里的划分没有绝对界限）：

宏观SOA：面向高层次的部门级别、公司级别甚至行业级别；涉及商业、管理、技术等方面的综合的、全局的考虑；架构体系上包括服务治理（governance，如服务注册，服务监控），服务编排（orchestration，如BPM，ESB)，服务协同（choreography，更多面向跨企业集成）等等。我认为SOA本身最主要是面向宏观层面的架构，其带来益处也最能在宏观高层次上体现出来，同时大部分SOA的业界讨论也集中在这方面。
微观SOA：面向有限的、局部的团队和个人；涉及独立的、具体的服务在业务、架构、开发上的考虑。

很多业界专家都认为SOA概念过于抽象，不接地气，我认为主要是宏观SOA涉及面太广，经常需要做通盘考虑，而其中很多方面距离一般人又比较远。而在微观层面的SOA更容易达到涛哥过去提出的“三贴近”：贴近实际、贴近生活、贴近群众。

同时，宏观SOA要取得成功，通常的前提也是SOA在微观层面的落地与落实，正如宏观经济学一般要有坚实的微观基础（比如大名鼎鼎的凯恩斯主义曾广受诟病的一点就是缺乏微观基础）

因此，我们着眼于SOA落地的目的，着重来分析微观SOA，也算是对业界主流探讨的一个小小的补充。

SOA定义

按照英文维基百科定义：SOA是一种“软件”和“软件架构”的设计模式（或者叫设计原则）。它是基于相互独立的软件片段要将自身的功能通过“服务”提供给其他应用。

什么是“服务”？按照OASIS的定义：Service是一种按照既定“接口“来访问一个或多个软件功能的机制（另外这种访问要符合“服务描述”中策略和限制）

SOA设计原则

既然SOA是设计原则（模式），那么它包含哪些内容呢？事实上，这方面并没有最标准的答案，多数是遵从著名SOA专家Thomas Erl的归纳：

标准化的服务契约 Standardized service contract 服务的松耦合 Service loose coupling 服务的抽象 Service abstraction 服务的可重用性 Service reusability 服务的自治性 Service autonomy 服务的无状态性 Service statelessness 服务的可发现性 Service discoverability 服务的可组合性 Service composability ....

这些原则总的来说要达到的目的是：提高软件的重用性，减少开发和维护的成本，最终增加一个公司业务的敏捷度。

但是，业界著名专家如Don Box，David Orchard等人对SOA又有各自不同的总结和侧重。

SOA不但没有绝对统一的原则，而且很多原则本身的内容也具备相当模糊性和宽泛性：例如，所谓松耦合原则需要松散到什么程度才算是符合标准的呢？这就好比一个人要帅到什么程度才算是帅哥呢？一栋楼要高到多少米才算是高楼呢？可能不同人心中都有自己的一杆秤……部分由于这些理论上的不确定因素，不同的人理解或者实施的SOA事实上也可能有比较大的差别。

浅析松耦合原则

SOA原则比较多，真正的理解往往需要逐步的积累和体会，所以在此不详细展开。这里仅以服务的松耦合为例，从不同维度来简单剖析一下这个原则，以说明SOA原则内涵的丰富性：