大量互联网公司都在拥抱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是一种按照既定“接口“来访问一个或多个软件功能的机制(另外这种访问要符合“服务描述”中策略和限制)
Service示例(代码通常以java示例)
public interface Echo { String echo(String text); } public class EchoImpl implements Echo { public String echo(String text) { return text; } }
可能每个开发人员每天都在写类似的面向对象的Service,难道这就是在实施SOA吗?
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原则内涵的丰富性:
-
实现的松耦合:这是最基本的松耦合,即服务消费端不需要依赖服务契约的某个特定实现,这样服务提供端的内部变更就不会影响到消费端,而且消费端未来还可以自由切换到该契约的其他提供方。
-
时间的松耦合:典型就是异步消息队列系统,由于有中介者(broker),所以生产者和消费者不必在同一时间都保持可用性以及相同的吞吐量,而且生产者也不需要马上等到回复。
-
位置的松耦合:典型就是服务注册中心和企业服务总线(ESB),消费端完全不需要直接知道提供端的具体位置,而都通过注册中心来查找或者服务总线来路由。
-
版本的松耦合:消费端不需要依赖服务契约的某个特定版本来工作,这就要求服务的契约在升级时要尽可能的提供向下兼容性。
SOA与传统软件设计
我们可以认为:SOA ≈ 模块化开发 + 分布式计算
将两者传统上的最佳实践结合在一起,基本上可以推导出SOA的多数设计原则。SOA从软件设计(暂不考虑业务架构之类)上来讲,自身的新东西其实不算很多。
SOA原则的应用
基于SOA的原则,也许我们很难说什么应用是绝对符合SOA的,但是却能剔除明显不符合SOA的应用。
用上述标准化契约,松耦合和可重用这几个原则来尝试分析一下上面Echo示例:
-
Echo的服务契约是用Java接口定义,而不是一种与平台和语言无关的标准化协议,如WSDL,CORBA IDL。当然可以抬杠,Java也是行业标准,甚至全国牙防组一致认定的东西也是行业标准。
-
Java接口大大加重了与Service客户端的耦合度,即要求客户端必须也是Java,或者JVM上的动态语言(如Groovy、Jython)等等……
-
同时,Echo是一个Java的本地接口,就要求调用者最好在同一个JVM进程之内……
-
Echo的业务逻辑虽然简单独立,但以上技术方面的局限就导致它无法以后在其他场合被轻易重用,比如分布式环境,异构平台等等。
因此,我们可以认为Echo并不太符合SOA的基本设计原则。
透明化的转向SOA?
修改一下上面的Echo,添加Java EE的@WebServices注解(annotation)
@WebServices public class EchoImpl implements Echo { public String echo(String text) { return text; } }
现在将Echo发布为Java WebServices,并由底层框架自动生成WSDL来作为标准化的服务契约,这样就能与远程的各种语言和平台互操作了,较好的解决了上面提到的松耦合和可重用的问题。按照一般的理解,Echo似乎就成为比较理想的SOA service了。
但是……即使这个极端简化的例子,也会引出不少很关键的问题,它们决定SOA设计开发的某些难度:
- 将一个普通的Java对象通过添加注解“透明的”变成WebServices就完成了从面向对象到面向服务的跨越?
- 通过Java接口生成WSDL服务契约是好的方式吗?
- WebServices是最合适远程访问技术吗?
面向对象和面向服务的对比
面向对象(OO)和面向服务(SO)在基础理念上有大量共通之处,比如都尽可能追求抽象、封装和低耦合。
但SO相对于OO,又有非常不同的典型应用场景,比如:
-
多数OO接口(interface)都只被有限的人使用(比如团队和部门内),而SO接口(或者叫契约)一般来说都不应该对使用者的范围作出太多的限定和假设(可以是不同部门,不同企业,不同国家)。还记得贝佐斯原则吗?“团队必须做好规划与设计,以便未来把接口开放给全世界的程序员,没有任何例外”。
-
多数OO接口都只在进程内被访问,而SO接口通常都是被远程调用。
简单讲,就是SO接口使用范围比一般OO接口可能广泛得多。我们用网站打个比方:一个大型网站的web界面就是它整个系统入口点和边界,可能要面对全世界的访问者(所以经常会做国际化之类的工作),而系统内部传统的OO接口和程序则被隐藏在web界面之后,只被内部较小范围使用。而理想的SO接口和web界面一样,也是变成系统入口和边界,可能要对全世界开发者开放,因此SO在设计开发之中与OO相比其实会有很多不同。
小结
在前述比较抽象的SOA大原则的基础上,我们可尝试推导一些较细化和可操作的原则,在具体实践中体现SO的独特之处。
相关推荐
本文是上篇,着眼于微观SOA的定义,并简单分析其核心原则。由于SOA有相当的难度和门槛,不妨先从一个小故事说起,从中可以管窥一点SOA的大意和作用。按照亚马逊前著名员工SteveYegge著名的“酒后吐槽”,2002年左右...
学校微观政治:教育研究中另一个领域.docx
微观金融学及其数学基础 微观金融学是研究个人、企业和市场如何进行跨期资源配置的学科,旨在解决不确定环境下的资源配置问题。微观金融学的数学基础是随机最优控制方法,用于解决鲁宾逊式的跨期最优消费/投资决策...
综上所述,这份室分系统微观规划设计原则综合考虑了室分系统的各个方面,从基础资料搜集、天线口功率设置到信源配置、功率一致性以及特殊场景处理等,都给出了详尽的指导。设计人员在遵循这些原则的同时,也应根据...
SOA 架构可以将所有的应用模块或功能设计成一个个功能组件(Components)或服务(Service),服务模块之间和功能组件之间采用松耦合和更加容易定义的方式进行集成,从而改善了应用的柔性化和可重用性。 在开发方面...
### 微观金融学及其数学基础 #### 一、金融的概念与核心问题 金融的本质是资金的融通或资本的借贷。从古希腊时代的第一张借据开始,金融就已经成为了连接消费与生产的桥梁,它是资源配置的重要手段。在不确定性...
《工业化、城镇化和农业现代化协调发展的微观机制:基于农户视角》这篇论文主要探讨了工业化、城镇化与农业现代化之间协调发展的微观机制,特别是从农户的角度进行分析。文章利用2009年河南省4200户农村住户抽样调查...
- **工程层面**:SOA的设计原则、实现方法、测试策略等。 - **操作层面**:SOA的部署、运维、监控等实践。 ### 国际研究组的组建 文档提出建立一个国际性的SOA研究小组的目标,旨在分析SOA的当前实践状态和研究...
为了研究脉动水力压裂煤层微观结构变化,对取自杨柳矿、顾桥矿和丁集矿的煤样进行脉动水力压裂实验室实验,通过压汞实验和CO2气体吸附测试分析原煤样和水力压裂作用下煤样孔隙特征变化规律。结果表明:原煤大孔隙阶段的...
《大数据与社会认识论:追本溯源、领域拓展及其实践探索》是一本深入探讨大数据对社会认知影响的重要著作。本书全面解析了大数据的概念、来源、发展脉络,并将其与社会认识论相结合,揭示了大数据在现代社会中的核心...
### 表面微观缺陷检测方法及其应用研究 #### 摘要解读 本文档探讨了基于多技术融合的表面微观缺陷检测方法,并结合物体成像、云计算、人工智能和5G等前沿技术,构建了一个用于精确检测微观领域缺陷的系统。这种方法...
【数学微观教学设计】是教育领域中关注的重点,它涉及到课堂...综上所述,数学微观教学设计是一门艺术与科学相结合的实践,要求教师具备深厚的学科知识,理解学生的学习需求,精心设计教学过程,以实现高效的教学效果。
本篇论文对互联网时代的终身学习大学构建进行了深入的探讨和分析,提出了终身学习大学构建的目标、原则、过程和策略,旨在为互联网时代的终身学习大学构建提供科学依据和实践指导。 关键词:互联网;终身学习;终身...
激光增材制造(LAM)涉及了复杂的热作用加工过程,在该工艺下制备的多层结构成形件也具有复杂的微观组织结构特征。而成形件的微观组织结构特征决定了其机械性能,优化微观组织结构特征是进一步实现机械性能的精确调控...
内契巴《微观经济学:直觉思维与数理方法》学习指导,2eThomas J. Nec hyba - Microeconomics An Intuitive Appro ach with Calculus 2e - Study Guide 样品资料供 下载前参考! sample.pdf (1.25 MB) 内契巴《微观...
2022年微观流动性展望:股票+基金:居民增配方向.pdf
其次,深入到微观层面,逐个分析关键的函数和类,理解它们的功能和实现方式。最后,通过运行代码和调试,观察其在不同情况下的行为,验证理解的正确性。 此外,使用科学的方法也是提高代码阅读效率的关键。这包括:...
在前文提到,此方法论旨在提炼一套从零到一设计商业化产品的通用框架,侧重于宏观设计逻辑,而非特定产品的微观设计细节。本篇将聚焦于交付设计的原则、标准以及流程。 #### 二、交付设计原则 交付设计的核心在于...