1. 前言
=========
随着当初互联网行业的倒退，越来越多的框架、中间件、容器等开源技术一直地涌现，更好地来服务于业务，实现业务并解决问题。然而面对泛滥的技术抉择，咱们要如何甄别出适宜本人团队业务的技术呢？对于人来说，鞋子过大，可能影响奔跑的速度，鞋子过小，可能影响身材的成长。技术对于业务也是如此的关系。
所以，绝对于技术的学习、搭建、应用、运维等技能，咱们对技术的甄别抉择更是重中之重。那么本文要讲的Dubbox框架，又是如何在泛滥的服务框架中怀才不遇，被团队选中践行服务之路？
===
2. 服务
======
2.1 为什么要做服务
技术为业务而生，架构也为业务而呈现。随着业务的倒退、用户量的增长，零碎数量增多，调用依赖关系也变得复杂，为了确保零碎高可用、高并发的要求，零碎的架构也从单体时代缓缓迁徙至服务SOA时代，依据不同服务对系统资源的要求不同，咱们能够更正当的配置系统资源，使系统资源利用率最大化。
零碎架构演进
1.繁多利用架构
当网站流量很小时，只需一个利用，将所有性能都部署在一起，以缩小部署节点和老本。
此时，用于简化增删改查工作量的数据拜访框架(ORM)是要害。
2.垂直利用架构
当访问量逐步增大，繁多利用减少机器带来的加速度越来越小，将利用拆成互不相干的几个利用，以晋升效率。
此时，用于减速前端页面开发的Web框架(MVC)是要害。
3.分布式服务架构
当垂直利用越来越多，利用之间交互不可避免，将外围业务抽取进去，作为独立的服务，逐步造成稳固的服务中心，使前端利用能更疾速的响应多变的市场需求。
此时，用于进步业务复用及整合的分布式服务框架(RPC)是要害。
3.流动计算架构
当服务越来越多，容量的评估，小服务资源的节约等问题逐步浮现，此时需减少一个调度核心基于拜访压力实时治理集群容量，进步集群利用率。
此时，用于进步机器利用率的资源调度和治理核心(SOA)是要害。
平台随着业务的倒退从 All in One 环境就能够满足业务需要（以Java来说，可能只是一两个war包就解决了）；倒退到需要拆分多个利用，并且采纳MVC的形式拆散前后端，放慢开发效率；在倒退到服务越来越多，不得不将一些外围或共用的服务拆分进去，提供实时流动监控计算等，其实倒退到此阶段，如果服务拆分的足够精密，并且独立运行，这个时候至多能够了解为SOA（Service-Oriented Architecture）架构了。
===
2.2 服务带来的挑战
当迎来服务SOA时代，咱们面临要解决的问题会很多，比方：零碎的复杂度回升、服务依赖关系、服务性能监控、全链路日志、容灾、断路器、限流等。那么面对这些问题为什么还要做分布式服务呢？因为在将来只有砥砺前行，能力走的更高更远。不过看到这些问题不要泄气，先不论这些问题，让咱们一步步来梳理下现存有什么问题，咱们要实现什么指标，问题天然会迎刃而解。
依据当初团队的业务零碎状况，首先咱们要梳理出现存的问题是什么：
那么，在抉择技术框架时，技术框架最根本要解决下面现存问题，同时咱们也要确认出咱们的冀望，要达到的指标是什么：
还有最重要一点，这也是往往很多技术人员进入的误区，“对于技术，不要为了应用而应用，用最简略适合的技术实现解决问题才是邪道”。架构是服务于业务的，能疾速不便的满足业务需要的架构才是好的架构。
没有最好的，只有适宜本人的
2.3 服务将来的趋势
一谈到服务，可能大家很多据说过SOA、MSA等服务的概念名词，近几年MSA炒的比拟火，其实每一个概念的背地都在解决不同的问题。此类名词的最大特点就是一解释就懂，一问就不知，一探讨就打架。
SOA、MSA两者说到底都是对外提供接口的一种架构设计形式。微服务其实就是随着互联网的倒退，简单的平台、业务的呈现，导致SOA架构向更细粒度、更通用化水平倒退，就成了所谓的微服务了。以这种说法做为依据，我感觉SOA与微服务的区别在于如下几个方面：
微服务与SOA有很多相同之处。两者都属于典型的、蕴含松耦合分布式组件的系统结构。在围绕着服务的概念创立架构这一方面，微服务提供了一种更清晰、定义更良好的形式。微服务的准则与麻利软件开发思维是高度一致的，而它与SOA准则的演变的指标也是雷同的，则缩小传统的企业服务总线开发的高复杂性。两者之间最要害的区别在于，微服务专一于以自治的形式产生价值。然而两种架构背地的用意是不同的：SOA尝试将利用集成，个别采纳地方管理模式来确保各利用可能交互运作。微服务尝试部署新性能，疾速无效地扩大开发团队。它着重于扩散治理、代码再利用与自动化执行。
微服务并不是一种新思维的办法。它更像是一种思维的精炼，一种SOA的精细化演进，并且更好地利用了先进的技术以解决问题，例如容器与自动化等。所以对于咱们去抉择服务技术框架时，并不是非黑即白，而是针对SOA、MSA两种架构设计同时要思考到兼容性，对于现有平台状况架构设计，退则守SOA，进则攻MSA，阶段性抉择适宜的。
===
3. 框架
当初业界比拟成熟的服务框架有很多，比方：Hessian、CXF、Dubbo、Dubbox、Spring Cloud、gRPC、thrift等技术实现，都能够进行近程调用，具体技术实现优劣参考以下剖析，这也是具体在技术计划抉择过程中的重要依据。
3.1 服务框架比照
Dubbo是阿里巴巴公司开源的一个Java高性能优良的服务框架，使得利用可通过高性能的 RPC 实现服务的输入和输出性能，能够和 Spring框架无缝集成。不过，略有遗憾的是，据说在淘宝外部，dubbo因为跟淘宝另一个相似的框架HSF（非开源）有竞争关系，导致dubbo团队曾经遣散，反到是当当网的扩大版本Dubbox仍在继续倒退，墙内开花墙外香。其它的一些出名电商如当当、国美保护了本人的分支或者在dubbo的根底开发，然而官网的库不足保护，相干的依赖类比方Spring，Netty还是很老的版本(Spring 3.2.16.RELEASE, netty 3.2.5.Final),倒是有些网友写了降级Spring和Netty的插件。
Dubbox和Dubbo实质上没有区别，名字的含意扩大了Dubbo而已，以下扩大进去的性能，也是抉择Dubbox很重要的考察点。
Spring Cloud齐全基于Spring Boot，是一个十分新的我的项目，2016年推出1.0的release版本，目前Github上更新速度很快. 尽管Spring Cloud工夫最短, 然而相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。Spring Cloud 为开发者提供了在分布式系统（配置管理，服务发现，熔断，路由，微代理，管制总线，一次性token，全局琐，leader选举，分布式session，集群状态）中疾速构建的工具，应用Spring Cloud的开发者能够疾速的启动服务或构建利用。它们将在任何分布式环境中工作，包含开发人员本人的笔记本电脑，裸物理机的数据中心，和像Cloud Foundry云治理平台。在将来引领这微服务架构的倒退，提供业界规范的一套微服务架构解决方案。
毛病是我的项目很年老，很少见到国内业界有人在生产上成套应用，个别都是只有其中一两个组件。相干的技术文档大部分是英文的，案例也绝对较少，应用的话须要摸索的工夫会长一些。
下图是Spring Cloud和Dubbo比照：
Spring Cloud和Dubbo比照
Motan是新浪微博开源的一个Java 框架。它诞生的比拟晚，起于2013年，2016年5月开源。Motan 在微博平台中曾经广泛应用，每天为数百个服务实现近千亿次的调用。与Dubbo相比，Motan在性能方面并没有那么全面，也没有实现特地多的扩大。用的人比拟少，性能和稳定性有待张望。对跨语言调用反对较差，次要反对java。
Hessian采纳的是二进制RPC协定，实用于发送二进制数据。但自身也是一个Web Service框架对RPC调用提供反对，性能简略，应用起来也不便。基于Http协定进行传输。通过Servlet提供近程服务。通过Hessain自身提供的API来发动申请。响应端依据Hessian提供的API来承受申请。
Hessian长处：
rpcx是Go语言生态圈的Dubbo， 比Dubbo更轻量，实现了Dubbo的许多个性，借助于Go语言优良的并发个性和简洁语法，能够应用较少的代码实现分布式的RPC服务。
gRPC是Google开发的高性能、通用的开源RPC框架，其由Google次要面向挪动利用开发并基于HTTP/2协定规范而设计，基于ProtoBuf(Protocol Buffers)序列化协定开发，且反对泛滥开发语言。自身它不是分布式的，所以要实现下面的框架的性能须要进一步的开发。
thrift是Apache的一个跨语言的高性能的服务框架，也失去了宽泛的利用。
以上RPC框架性能比拟：
理论场景中的抉择
3.2 RPC vs REST(JAX-RS)
因为Dubbo是根底框架，其实现的内容对于咱们施行微服务架构是否正当，也须要咱们依据本身需要去思考是否要批改，比方Dubbo的服务调用是通过RPC实现的，然而如果认真拜读过Martin Fowler的microservices一文，其定义的服务间通信是HTTP协定的REST API。那么这两种有何区别呢？
1.服务提供方与调用方接口依赖形式太强
咱们为每个微服务定义了各自的service形象接口，并通过继续集成公布到公有仓库中，调用方利用对微服务提供的形象接口存在强依赖关系，因而不管开发、测试、集成环境都须要严格的治理版本依赖，才不会呈现服务方与调用方的不统一导致利用无奈编译胜利等一系列问题，以及这也会间接影响本地开发的环境要求，往往一个依赖很多服务的下层利用，每天都要更新很多代码并install之后能力进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依附一纸契约，不存在代码级别的强依赖，当然REST接口也有痛点，因为接口定义过轻，很容易导致定义文档与理论实现不统一导致服务集成时的问题，然而该问题很好解决，只须要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST形式的服务依赖要比RPC形式的依赖更为灵便。
2.服务对平台敏感，难以简略复用
通常咱们在提供对外服务时，都会以REST的形式提供进来，这样能够实现跨平台的特点，任何一个语言的调用方都能够依据接口定义来实现。那么在Dubbo中咱们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外公布。若咱们每个服务自身就以REST接口方式存在，当要对外提供服务时，次要在API网关中配置映射关系和权限管制就可实现服务的复用了。
置信这些痛点也是为什么当当网在dubbox（基于Dubbo的开源扩大）中减少了对REST反对的起因之一。
Dubbo实现了服务治理的根底，然而要实现一个齐备的微服务架构，还须要在各环节去扩大和欠缺以保障集群的衰弱，以加重开发、测试以及运维各个环节上减少进去的压力，这样能力让各环节人员真正的专一于业务逻辑。
而Spring Cloud仍然发挥了Spring Source整合所有的风格，以标准化的姿势将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简略配置、疾速开发、轻松部署的特点，让本来简单的架构工作变得绝对容易上手一些。
所以，如果抉择Dubbo请务必在各个环节做好整套解决方案的筹备，不然很可能随着服务数量的增长，整个团队都将疲于应酬各种架构上有余引起的艰难。而如果抉择Spring Cloud，相对来说每个环节都曾经有了对应的组件反对，可能有些也不肯定能满足你所有的需要，然而其沉闷的社区与高速的迭代进度也会是你能够依附的弱小后盾。
微服务结构图
4. Dubbox带来什么
=================
4.1 Dubbo服务治理
Dubbo服务治理