你如何考虑服务化

面向服务的架构

面向服务架构（Service-Oriented Architecture，SOA）又称“面向服务的体系结构”，是Gartner于2O世纪9O年代中期提出的面向服务架构的概念。

面向服务架构，从语义上说，它与面向过程、面向对象、面向组件一样，是一种软件组建及开发的方式。与以往的软件开发、架构模式一样，SOA 只是一种体系、一种思想，而不是某种具体的软件产品。

这里，我们通过一个例子来解释一下到底什么是 SOA？如何做到 SOA？

什么是 SOA

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

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

这些原则总的来说要达到的目的是：提高软件的重用性，减少开发和维护的成本，最终增加一个公司业务的敏捷度。既然是面向服务的架构，那么我们就先来定义一个服务，

public interface Echo {
    String echo(String text);
}

public class EchoImpl implements Echo {
    public String echo(String text) {
        return text;
    }
}

上面这段代码相信有过 JavaWeb 开发经验的人都不会陌生。就是定义了一个服务的接口和实现。

那么，定义了服务，我们就做到了 SOA 了么？

我们用 Thomas Erl 定义的原则来对比一下，用松耦合和可重用这几个原则来尝试分析一下上面 Echo 示例：

Echo 的服务契约是用 Java 接口定义，而不是一种与平台和语言无关的标准化协议，如 WSDL，CORBA IDL。当然可以抬杠，Java 也是行业标准，甚至全国牙防组一致认定的东西也是行业标准。
Java 接口大大加重了与 Service 客户端的耦合度，即要求客户端必须也是 Java，或者 JVM 上的动态语言（如Groovy、Jython）等等……
同时，Echo 是一个 Java 的本地接口，就要求调用者最好在同一个 JVM 进程之内……
Echo 的业务逻辑虽然简单独立，但以上技术方面的局限就导致它无法以后在其他场合被轻易重用，比如分布式环境，异构平台等等 ESB 是 SCA 思想实现的基础设施。ESB 主要作用是集中注册发布服务，为服务与传输协议之间解耦。并不是所有的 SOA 架构都需要 ESB，ESB 是 SCA 特有的。当然任何符合 ESB 特征的解决方式都可以称之为 ESB，也不仅仅是 SCA 内部的。

因此，我们可以认为 Echo 并不太符合 SOA 的基本设计原则。

实现 SOA

修改一下上面的 Echo，添加 Java EE 的 @WebServices 注解

@WebServices
public class EchoImpl implements Echo {
    public String echo(String text) {
        return text;
    }
}

现在将 Echo 发布为 Java WebServices，并由底层框架自动生成 WSDL 来作为标准化的服务契约，这样就能与远程的各种语言和平台互操作了，较好的解决了上面提到的松耦合和可重用的问题。按照一般的理解，Echo 似乎就成为比较理想的 SOA service了。

使用 WebServices 只是一种相对简单的方案，SOA 的最常见的解决方案是 SCA，其次还有 JBI，BPEL 等。ESB 是 SCA 思想实现的基础设施。ESB 主要作用是集中注册发布服务，为服务与传输协议之间解耦。关于 SCA 和 ESB 并不是本文的重点，感兴趣的朋友可以从网络上获取更多资料。(可以从上图中看到 ESB 在整个 SOA 架构中所扮演的角色)

面向对象和面向服务的对比

面向对象（OO）和面向服务（SO）在基础理念上有大量共通之处，比如都尽可能追求抽象、封装和低耦合。

但 SO 相对于 OO，又有非常不同的典型应用场景，比如：

多数 OO 接口（interface）都只被有限的人使用（比如团队和部门内），而 SO 接口（或者叫契约）一般来说都不应该对使用者的范围作出太多的限定和假设（可以是不同部门，不同企业，不同国家）。还记得贝佐斯原则吗？“团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外”。
多数 OO 接口都只在进程内被访问，而 SO 接口通常都是被远程调用。

简单讲，就是 SO 接口使用范围比一般 OO 接口可能广泛得多。我们用网站打个比方：一个大型网站的 web 界面就是它整个系统入口点和边界，可能要面对全世界的访问者（所以经常会做国际化之类的工作），而系统内部传统的 OO 接口和程序则被隐藏在 web 界面之后，只被内部较小范围使用。而理想的 SO 接口和 web 界面一样，也是变成系统入口和边界，可能要对全世界开发者开放，因此 SO 在设计开发之中与 OO 相比其实会有很多不同。

微服务架构

微服务架构(MicroService)是一种服务化架构风格，通过将功能分散到各个离散的服务中以实现对解决方案的解耦。微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化（这也是我们为什么要先介绍组件化和服务化的原因）。微服务的诞生并非偶然。它是互联网高速发展，敏捷、精益、持续交付方法论的深入人心，虚拟化技术与 DevOps 文化的快速发展以及传统单块架构无法适应快速变化等多重因素的推动下所诞生的产物。

微服务的流行，Martin 功不可没，先看看他是如何定义微服务的：