一，什么是微服务

0.背景

首先要理解一下大背景，随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

图源来自Dubbo文档：

从图上我们可以看出，随着业务能力的需求，机器节点越来越多，我们从ORM的单一应用架构慢慢成长到MVC垂直应用架构，然后把核心业务抽取出来形成分布式服务框架RPC，到增加调度中心的流动计算框架SOA。整个背景都是趋于让服务框架更有利于服务的形势，把服务越分越细，功能越来越全，并有网络调度和容错能力。

单体系统的缺点：
项目过于臃肿，难以维护；
资源无法隔离，容错率低；
无法灵活扩展，工作量大；

一些解决问题的方法：

SOA面向服务架构：是一种设计方法，服务之间通过网络调用，而非采用进程间调用方式进行通信。要注意的是SOA是一种设计思想，是大概念，具体实行的通信协议SOAP，第三方中间件，服务粒度都没有确定，只是提出我们可以用这种方式解决存在的问题。

共享库：代码库可以分成多个库，我们可以围绕库来进行组织和共享，通过共享代码做到服务之间的通信。缺点也显而易见，有点类似于MVC的架构，由于没有中间件，而且耦合点多，使得效果没有SOA好。

模块：有些语言提供模块分解技术（java9也提供），它们允许对模块进行生命周期管理，这样就可以模块部署到进程并支持修改，如OSGI和Erlang。进程中模块隔离技术性比较强，而且还是容易导致过度耦合。

1.概念

基于这个问题，微服务框架这个概念诞生，微服务就是一些协同工作的小而自治的服务。

微服务把服务的代码库做到足够小，服务之间通过网络调用进行通信，彼此可以独立修改，使用API实现消费方解耦能力并提供服务。

2.优势

所以优势就对应于单体系统的缺点，技术异构性高，资源有效隔离，可扩展性强，优化可替代性。这里想多说一下技术异构性，我们可以使用风险最小的服务采用新技术，还可以用不同的技术编写服务和客户端。

3.框架

市场上经典的微服务框架就是Dubbo和Spring cloud，下面以他们两个为例 对微服务框架有更深的认识。

二，Dubbo

官网：http://dubbo.apache.org/zh-cn/docs/user/quick-start.html

Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。
Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。想到了上篇博客提到的分布式事务的2PC。

用法

可以通过spring配置，本地配置local.xml

<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
    <property name=“xxxService” ref=“xxxService” />
</bean>

在本地服务的基础上，只需做简单配置，即可完成远程化：

    将上面的 local.xml 配置拆分成两份，将服务定义部分放在服务提供方 remote-provider.xml，将服务引用部分放在服务消费方 remote-consumer.xml。
    并在提供方增加暴露服务配置 <dubbo:service>，在消费方增加引用服务配置 <dubbo:reference>。

remote-provider.xml:

<!-- 和本地服务一样实现远程服务 -->
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” /> 
<!-- 增加暴露远程服务配置 -->
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” /> 

remote-consumer.xml:

<!-- 增加引用远程服务配置 -->
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” />
<!-- 和本地服务一样使用远程服务 -->
<bean id=“xxxAction” class=“com.xxx.XxxAction”> 
    <property name=“xxxService” ref=“xxxService” />
</bean>

Dubbo 采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo 的配置即可，Dubbo 基于 Spring 的 Schema 扩展 进行加载。

dubbo的具体框架设计：http://dubbo.apache.org/zh-cn/docs/dev/design.html

我们可以看到Dubbo有一个注册中心Registry的概念，服务的提供者Provider将服务注册到Registry，消费者Consumer需要从Registry中发现、监听到服务的变动；Provider需要运行在Container容器中，另外Dubbo提供Monitor来对服务的调用次数以及调用时间进行监控。常用的Registry有Zookeeper，Redis等；

三，Spring cloud

官网：https://spring.io/projects/spring-cloud
Spring Cloud的目的是微服务架构下的一站式解决方案，而Dubbo类似于Spring Cloud的一个子集。

一张比较火的对比图就可以看出不同：

架构完整度上，spring是最全的微服务架构，为开发者提供了在分布式系统的配置管理、服务发现、断路器、智能路由、微代理、控制总线等开发工具包。

另一个不同是Dubbo的服务调用通过RPC实现，这就导致服务提供方调用方对接口依赖太强。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。

spring cloud架构

四，其他补充

远程服务调用

大致上讲，RPC（远程过程调用）采用客户机/服务器模式实现两个进程之间相互通信。一般是Tcp连接，建立进程间连接，序列化和反序列化接收。通信中的协议是自己规定的，有专用的API配合。

REST用URL定位资源，用HTTP动词（GET,POST,DELETE）描述操作。

微服务架构中提到RPC实现RMI的脆弱性，自动生成的二进制桩代码通常会冗余，因为系统往往没有意识到做远程调用还是本地调用，使用的数据类型直接序列化反序列化，修改或删除无法做到精确。REST的引入避免客户端和服务器产生耦合。

服务发现

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互 感知？服务如何管理？这就是服务发现的问题了。一般基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当 服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。

由于负载均衡，容错，数据库扩展等在架构里涉及到的比较多，简言几句讲了也没有什么用就不赘述了，最后在设计方面，由于在分布式系统中我们无法避免延迟和失败，就要采用一系列分布式事务的治理方法，并符合我们的业务需求，微服务框架就是其中之一。这篇文章我们简述了微服务框架的由来和概念，并简介了两个采用微服务框架的热门工程，稍微补充了下RPC和REST的概念和在微服务框架的作用，希望做一个引路科普材料，对微服务框架有个大致的了解，详尽技术希望以后有时间可以补充。

参考材料：《微服务设计》，dubbo官方文档，

博客：https://blog.csdn.net/wuxiaobingandbob/article/details/78642020

http://blog.didispace.com/microservice-framework/