http://www.Sina.com/http://www.Sina.com /
首先要了解大背景，随着互联网的发展，网站APP应用的规模不断扩大，普通的垂直APP架构已经无法适应，分布式服务架构和移动计算架构势在必行
图源来自Dubbo文档：
如图所示，随着业务能力的需求，机器节点不断增加，从ORM的单一APP架构逐渐成长为MVC垂直APP架构，提取核心业务形成分布式服务框架RPC，调度中心的流程图整个背景下，服务架构倾向于有利于服务，服务划分越精细，功能越完善，网络调度和容错能力越强。
一，什么是微服务
项目太臃肿，很难维护
资源无法隔离，容错能力低
无法灵活扩展，工作量大
0.背景
面向SOA服务的体系结构：一种通过网络在服务之间通信的设计方法，而不是进程间调用方法。 需要注意的是，SOA是一种设计思想，是一个很大的概念，具体运行的通信协议SOAP、第三方中间件、服务的粒度还没有确定，只是提出了我们可以用这种方法解决存在的问题。
共享库：代码库可以分为多个库，可以以库为中心组织和共享，通过共享代码进行服务器之间的通信。 坏处也很明显，类似于MVC的体系结构。 因为没有中间件，结合点多，所以效果没有SOA好。
模块：有些语言提供了java9也提供的模块分解技术。 这提供了模块的生命周期管理，使您可以将模块部署到流程中，并支持OSGI和Erlang等更改。 过程中的模块隔离技术比较强，且仍容易导致过度耦合。
单体系统的缺点：
基于这个问题，微服务框架的概念应运而生，微服务是一些协同工作的小自主服务。
微服务器可以充分缩小服务器的代码库，服务器之间通过网络呼叫通信，相互独立修改，使用API实现消费者端的解耦能力，提供服务。
一些解决问题的方法：
因此，优势应对单体系统的缺点，技术异构性高，资源有效隔离，可扩展性强，替代性优化。 现在我想谈谈技术的异构性，可以使用风险最小的服务采用新技术，也可以用不同的技术创建服务和客户端。
1.概念
市场的经典微服务框架是Dubbo和Spring cloud。 以下以他们两人为例对微服务框架有了更深入的认识。
2.优势官方网站： http://dubbo.Apache.org/zh-cn/docs/user/quick-start.html
Dubbo是阿里巴巴公司开源的高性能优秀服务框架，APP应用通过高性能的RPC实现服务的输出和输入功能，可以与Spring框架无缝集成。
Dubbo是一个高性能、轻量级的开源Java RPC框架，提供了三个主要功能：面向接口的远程方法调用、智能容错和负载平衡以及服务自动注册和检测考虑了上一个博客中提到的分布式事务的2PC。
3.框架
local.xml可以在spring配置中本地配置
bean id=" XXX service " class=" com.XXX.xxxserviceimpl "/bean id=" XXX action " class=" com.XXX.XXX action " prop
将上述local.xml配置拆分为两部分，将服务定义部分放在服务提供者remote-provider.xml中，将服务引用部分放在服务消费者remote-consumer.xml中。
在提供方添加暴露服务器以配置Dubbo:服务器，在消费者方添加引用服务器以配置dubbo:reference。
remote-provider.xml:
！ - -与本地服务一样实现远程服务---beanid=「XXX服务" class=" com.XXX.xxserviceimpl "/-添加暴露远程服务配置---Dubbo:服务器
！ -添加参考远程服务配置--dubbo : reference id=" XXX service " interface=" com.XXX.XXX service "/-将远程服务与本地服务一样
n” 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/