当前微服务很热，大家都号称在使用微服务架构，但究竟什么是微服务架构？微服务架构是不是发展趋势？对于这些问题，我们都缺乏清楚的认识，本文基于作者在大型互联网系统的服务化实践和思考，和大家一起探讨微服务架构。

本文主要内容包括：

传统SOA架构

新型SOA架构

服务设计方式

深入微服务

微服务体系

微服务系统架构

　　传统SOA架构

说到微服务，离不开SOA，两者经常放一起讨论，首先我们要了解SOA架构。

国外信息化起步较早，很多大公司先后建设了很多系统，比如从开始的ERP，到OA系统，到CRM系统等。由于这些系统往往由不同的供应商提供，采用不同的技术，实施的时候也没预先考虑到和现有系统集成，因此系统集成非常困难。

在2000年初的时候，两个概念非常流行，一个是EAI（Enterprise application integration），即企业应用集成；还有一个是EII（Enterprise application integration），即企业信息集成。一个从应用的角度，一个从数据的角度，本质是一回事，都是怎么把孤立的系统集成在一起。

SOA架构源自于企业内部异构系统的集成，具体做法是各个系统对外提供粗粒度的服务，外部系统可以通过相对标准的技术访问，大致结构如下图所示：

每个遗留系统提供服务，该服务作为系统的前置代理，对外提供访问。所有这些服务部署在一个中心化的平台，称之为企业服务总线ESB（Enterprise Service Bus），ESB提供复杂处理，包括：

外部访问

为满足不同客户端访问需求，提供各种各样的访问协议，如WebService、HTTP、FTP、Email等，其中WebService是最典型的通讯协议。

内部处理

请求进来后，需要一系列复杂处理，如对通讯协议的解析，数据的序列化和反序列化，业务流程的编排和服务路由等。

2008年的时候，eBay基于Axis，开发了自己的SOA框架，各个系统通过创建服务，对外提供功能。如后台搜索系统，本身是C++开发，通过对外提供Java服务，最终以WebService的方式，方便其他系统（大多是Java）调用搜索的功能。经过1年多的时间，整个SOA平台已经有上百个服务，很大程度上方便了系统相互集成。

但我们可以看到，ESB是一个很重的机制。首先通讯方式复杂，前后端涉及多种协议，由于每次调用代价很高，服务一般提供粗粒度的接口，一次性尽量完成更多处理。

ESB的中心化带来了单点故障隐患，服务统一在ESB上进行部署，也限制了服务的水平扩展；此外ESB还包含很多业务相关的功能，如业务流程编排等，限制了业务扩展的灵活性。

无论对于服务的提供者还是使用者，通过ESB这种方式集成，开发代价大，通信效率低，因此这种传统很重的SOA架构并没有得到大规模应用。

2008年的时候，eBay基于Axis，开发了自己的SOA框架，各个系统通过创建服务，对外提供功能。如后台搜索系统，本身是C++开发，通过对外提供Java服务，最终以WebService的方式，方便其他系统（大多是Java）调用搜索的功能。经过1年多的时间，整个SOA平台已经有上百个服务，很大程度上方便了系统相互集成。

但我们可以看到，ESB是一个很重的机制。首先通讯方式复杂，前后端涉及多种协议，由于每次调用代价很高，服务一般提供粗粒度的接口，一次性尽量完成更多处理。

ESB的中心化带来了单点故障隐患，服务统一在ESB上进行部署，也限制了服务的水平扩展；此外ESB还包含很多业务相关的功能，如业务流程编排等，限制了业务扩展的灵活性。

无论对于服务的提供者还是使用者，通过ESB这种方式集成，开发代价大，通信效率低，因此这种传统很重的SOA架构并没有得到大规模应用。

　　新型SOA架构

这里应用直接调用服务，无需经过复杂的中心节点，使用轻量级的协议，一般是HTTP，数据格式也很简单，比如JSON，由服务提供者直接解析协议和数据格式。同时每个服务本身包含核心的业务封装，提供给多个应用场景。

此外每个服务独立部署，提供更好的灵活性，包括业务功能扩展和处理容量水平扩展。

我们可以看到，新型SOA和传统基于ESB的SOA相反，这里是强化服务终端能力，弱化通道连接。

　　服务如何设计

随着互联网业务越来越复杂，新型的SOA架构不断深入发展，出现了多种服务设计模式。

1. 面向业务系统服务设计

面向业务系统SOA把原单体应用里的业务逻辑层剥离出来，作为单独的服务对外提供。