微观微观SOA：服务设计原则及其实践方式：服务设计原则及其实践方式
微观SOA：服务设计原则及其实践方式（上篇）
大量互联网公司都在拥抱SOA和服务化，但业界对SOA的很多讨论都比较偏向高大上。本文试图从稍微不同的角度，以相对
接地气的方式来讨论SOA，集中讨论SOA在微观实践层面中的缘起、本质和具体操作方式，另外也用相当篇幅介绍了当今互
联网行业中各种流行的远程调用技术等等，比较适合从事实际工作的架构师和程序员来阅读。
为了方便阅读，本话题将分为两篇展现。本文是上篇，着眼于微观SOA的定义，并简单分析其核心原则。
亚马逊CEO杰夫?贝佐斯：鲜为人知的SOA大师
由于SOA有相当的难度和门槛，不妨先从一个小故事说起，从中可以管窥一点SOA的大意和作用。
按照亚马逊前著名员工Steve Yegge著名的“酒后吐槽”，2002年左右，CEO贝佐斯就在亚马逊强制推行了以下六个原则（摘自
酷壳）：
1.所有团队的程序模块都要以通过Service Interface 方式将其数据与功能开放出来。
2.团队间的程序模块的信息通信，都要通过这些接口。
3.除此之外没有其它的通信方式。其他形式一概不允许：不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用
共享内存模式、不能使用别人模块的后门、等等，等等，唯一允许的通信方式只能是能过调用 Service Interface。
4.任何技术都可以使用。比如：HTTP、Corba、Pubsub、自定义的网络协议、等等，都可以，贝佐斯不管这些。
5.所有的Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设
计，以便未来把接口开放给全世界的程序员，没有任何例外。
6.不这样的做的人会被炒鱿鱼。
据说，亚马逊网站展示一个产品明细的页面，可能要调用200-300个Service，以便生成高度个性化的内容。
Steve还提到：
Amazon已经把文化转变成了“一切以Service第一”为系统架构的公司，今天，这已经成为他们进行所有设计时的基础，包括那
些绝不会被外界所知的仅在内部使用的功能。
那时，如果没有被解雇的的恐惧他们一定不会去做。我是说，他们今天仍然怕被解雇，因为这基本上是那儿每天的生活，为那
恐怖的海盗头子贝佐斯工作。不过，他们这么做的确是因为他们已经相信Service这就是正确的方向。他们对于SOA的优点和
缺点没有疑问，某些缺点还很大，也不疑问。但总的来说，这是正确的，因为，SOA驱动出来的设计会产生出平台
（Platform）。
今天，我们都知道亚马逊从世界上最大图书卖场进化为了世界上最成功的云平台……
贝佐斯的六原则展示出高度的远见和超强的信念，即使放到十几年后的今天，依然觉得振聋发聩……想起一句老话：“不谋万
世者，不足以谋一时；不谋全局者，不足以谋一隅。”
当然，像贝佐斯这种将神性与魔性集于一身的专横人物，既可能创造划时代的进步，也可能制造前所未有的灾难。
SOA漫谈：宏观与微观
SOA即面向服务架构，是一个特别大的话题。
为了方便讨论，我在此先草率的将SOA分为两个层面（大概模仿宏观和微观经济学，但这里的划分没有绝对界限）：
1.宏观SOA：面向高层次的部门级别、公司级别甚至行业级别；涉及商业、管理、技术等方面的综合的、全局的考虑；架构体
系上包括服务治理（governance，如服务注册，服务监控），服务编排（orchestration，如BPM，ESB)，服务协同
（choreography，更多面向跨企业集成）等等。我认为SOA本身最主要是面向宏观层面的架构，其带来益处也最能在宏观高
层次上体现出来，同时大部分SOA的业界讨论也集中在这方面。
2.微观SOA：面向有限的、局部的团队和个人；涉及独立的、具体的服务在业务、架构、开发上的考虑。
很多业界专家都认为SOA概念过于抽象，不接地气，我认为主要是宏观SOA涉及面太广，经常需要做通盘考虑，而其中很多
方面距离一般人又比较远。而在微观层面的SOA更容易达到涛哥过去提出的“三贴近”：贴近实际、贴近生活、贴近群众。
同时，宏观SOA要取得成功，通常的前提也是SOA在微观层面的落地与落实，正如宏观经济学一般要有坚实的微观基础（比
如大名鼎鼎的凯恩斯主义曾广受诟病的一点就是缺乏微观基础）
因此，我们着眼于SOA落地的目的，着重来分析微观SOA，也算是对业界主流探讨的一个小小的补充。
SOA定义
剩余9页未读，继续阅读
资源评论
