Dubbo分布式 RPC 服务框架
Dubbo 详细介绍
Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。
主要核心部件：
?Remoting:网络通信框架，实现了 sync-over-async 和 request-response 消息机制
?RPC:一个远程过程调用的抽象，支持负载均衡、容灾和集群功能
?Registry:服务目录框架用于服务的注册和服务事件发布和订阅Dubbo 工作原理
?Provider
?暴露服务方称之为“服务提供者”
?Consumer
?调用远程服务方称之为“服务消费者”
?Registry
?服务注册与发现的中心目录服务称之为“服务注册中心”
?Monitor
?统计服务的调用次调和调用时间的日志服务称之为“服务监控中心”
(1) 连通性：
?注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
?监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
?服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
?服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
?注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
?注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
?注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
?注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
(2) 健状性：
?监控中心宕掉不影响使用，只是丢失部分采样数据
?数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务?注册中心对等集群，任意一台宕掉后，将自动切换到另一台
?注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
?服务提供者无状态，任意一台宕掉后，不影响使用
?服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
(3) 伸缩性：
?注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
?服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者
码云极速下载/dubbo
Star 24 | Fork 0
Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC 实现服务的输出和输入功能，可以和 Spring 框架无缝集成
Java分布式架构
介绍 1. 项目核心代码结构截图
基于SpringCloud微服务系统设计方案
微服务系统设计方案 1.微服务本质 微服务架构从本质上说其实就是分布式架构，与其说是一种新架构，不如说是一种微服务架构风格。 简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互。多数情况下是一个HTTP的资源API。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。 对于微服务架构系统，由于其服务粒度小，模块化清晰，因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。 本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。 理解微服务架构和理念是核心。 2.系统环境
3.微服务架构的挑战 可靠性： 由于采用远程调用的方式，任何一个节点、网络出现问题，都将使得服务调用失败， 随着微服务数量的增多，潜在故障点也将增多。 也就是没有充分的保障机制，则单点故障会大量增加。 运维要求高： 系统监控、高可用性、自动化技术 分布式复杂性： 网络延迟、系统容错、分布式事务 部署依赖性强： 服务依赖、多版本问题 性能（服务间通讯成本高）： 无状态性、进程间调用、跨网络调用 数据一致性： 分布式事务管理需要跨越多个节点来保证数据的瞬时一致性，因此比起传统的单体架构的事务，成本要高得多。另外，在分布式系统中，通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。 重复开发： 微服务理念崇尚每个微服务作为一个产品看待，有自己的团队开发，甚至可以有自己完全不同的技术、框架，那么与其他微服务团队的技术共享就产生了矛盾，重复开发的工作即产生了。
基于微服务架构的基础设施设计
基于微服务架构的基础设施设计 摘要：本文首先分析传统的单体架构进而解释微服务架构以及分布式环境下四层架构，详细分析了迁移需解决的关键问题如服务间通信机制、数据最终一致性等；然后分析了分布式系统核心问题和DevOps基本原则，以此为设计依据提出微服务架构基础设施总体设计，并且对其关键组件如服务注册与发现、持续交付平台、服务网关的实施提出具体方案；最后针对微服务架构基础设施在运维管理中的应用场景进行了探讨，说明了微服务架构设计思想优于单体架构设计思想。 关键词：软件工程；微服务；服务注册与发现；持续交付 中图分类号：TP311.5 文献标识码：A DOI： 10.3969/j.issn.1003 6970.2016.05.023 本文著录格式：蒋勇.基于微服务架构的基础设施设计卟软件，2016，37（5）：93-97 0.引言 理论上任何业务系统如果长期存在的话，随着此系统业务变更、功能增加必然会不断演变，在一个更大的分布式环境中，这种改变尤其明显，那么就需要架构分析设计时更多的考虑系统所处的生态环境建设，这样才能使得整个系统不
断进化。随着虚拟化技术的发展以及docker容器实践逐渐完善，微服务架构的设计思想逐渐浮出水面，形成分布式环境下新的最重要的设计思想。文献对分布式环境下资源及应用平台进行了研究，但对于应用自身依赖的基础设施建设没有讨论。本文将详细探讨如何基于微服务架构进行基础设施建设的设计与分析。 1.从分布式单体架构到微服务架构迁移 1.1分布式单体架构 分布式单体架构指的是在分布式环境下直接部署运行 一个整体开发的应用，由整体应用来提供系统所需的服务，它在技术上通常采用分层实现，大致分为表现层、应用层、数据层，它有天然的优势：它是模块独立无关的，各层之间是技术分离的；它有统一的技术栈和开发标准；它通常在一个进程中运行，模块相互之间协同消耗极小。 但是，在分布式环境下，随着系统功能的增加，系统越来越复杂，单体架构存在一些必然的缺陷：首先，由于整个系统是一个完整整体，必须重复部署多个才能提高系统性能，而往往系统瓶颈仅仅由于其中某一个或几个功能过载产生，这就极大浪费了运行环境资源；其次，由于系统功能的变更和演变，某一个功能的变化可能影响其它功能的正常结果，也带来重新部署和运维管理的复杂性，持续集成变得极为困难；最后，由于整个系统采用统一的技术栈和开发标准，必
分布式服务架构方案
高并发分布式服务架构方案 下图是一个非常全面的架构蓝图，针对不同的应用系统需要的模块各有不同。此架构方案主要包括以下几个方面的设计：数据存储和读取，基础服务，应用层（APP/业务/Proxy），日志监控等，下面对这些主要的问题提供具体的各项针对性技术方案。 数据的存储和读取 分布式系统应该根据应用对数据不同的一致性、可用性等要求和数据的不同特性，采用不同的数据存储和读取方案，主要有以下几种可选方案： 1)内存型数据库。内存型的数据库，以高并发高性能为目标，在事务性方面没那么严格， 适合进行海量数据的存储和读取。例如开源nosql数据库mongodb、redis等。 2)关系型数据库。关系型数据库在满足并发性能的同时，也需要满足事务性，可通过 读写分离，分库分表来应对高并发大数据量的情况。例如Oracle，Mysql等。 3)分布式数据库。对于数据的高并发的访问，传统的关系型数据库提供读写分离的方案， 但是带来的确实数据的一致性问题提供的数据切分的方案；对于越来越多的海量数据，传统的数据库采用的是分库分表，实现起来比较复杂，后期要不断的进行迁移维护；对
于高可用和伸缩方面，传统数据采用的是主备、主从、多主的方案，但是本身扩展性比较差，增加节点和宕机需要进行数据的迁移。对于以上提出的这些问题，分布式数据库HBase有一套完善的解决方案，适用于高并发海量数据存取的要求。 基础服务 基础服务主要是指数据层之上的数据路由，Cache，搜索等服务。 1)路由Router。对于数据库切分方案中的分库分表问题，需要解决在请求对应的数据时 定位需要访问的位置，可根据一致性Hash，维护路由表至内存数据库等方案解决。 2)Cache。对于高并发的系统来讲，使用Cache可以减轻对后端系统的压力，所有Cache 可承担大部分热数据的读操作。当前用的比较多的是redis和memcache，redis比memcache有丰富的数据操作的API，redis对数据进行了持久化，而memcache没有这个功能，因此memcache更加适合在关系型数据库之上的数据的缓存。 3)搜索。搜索可以支持应用系统的按照关键词的检索，搜索提示，搜索排序等功能。开源 开源的企业级搜索引擎主要有lucene, sphinx，选择搜索引擎主要考虑以下三个方面： a)搜索引擎是否支持分布式的索引和搜索，来应对海量的数据，支持读写分离，提高 可用性 b)索引的实时性 c)搜索引擎的性能 Solr是基于Lucene开发的高性能的全文搜索服务器，满足以上三个方面的考虑，而且目前在企业中应用非常广泛。 应用层 应用层主要包括面向用户的应用，网站、APP等，还包括相关的业务处理的运算等。 1)负载均衡-反向代理。一个大型的平台包括很多个业务域，不同的业务域有不同的集群， 可以用DNS做域名解析的分发或轮询，DNS方式实现简单。但是因存在cache而缺乏灵活性；一般基于商用的硬件F5、NetScaler或者开源的软负载lvs在做分发，当然会采用做冗余(比如lvs+keepalived)的考虑，采取主备方式。Nginx是基于事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器/反向代理软件，可用作反向代理的工具。
微服务架构设计V1
微服务架构设计
目录 一、微服务架构介绍 (3) 二、微服务出现和发展 (3) 三、传统开发模式和微服务的区别 (4) 四、微服务的具体特征 (7) 五、SOA和微服务的区别 (9) 六、怎么具体实践微服务 (11) 七、常见的设计模式和应用 (17) 八、优点和缺点 (23) 九、思考：意识的转变 (26)
一、微服务架构介绍 微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的 类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。 概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。 定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。 本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。 二、微服务出现和发展 微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年； 越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。而微服务的流行，Martin Fowler功不可没。 这老头是个奇人，特别擅长抽象归纳和制造概念。特别是微服务这种新生的名词，都有一个特点：一解释就懂，一问就不知，一讨论就打架。
分布式服务框架Dubbo及相关组件集成
1.D ubbo介绍 1.1.简介 Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。 Dubbo最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。 上图中，蓝色方块表示与业务有交互，绿色方块表示只对Dubbo内部交互。上述图所描述的调用流程如下： 1)服务提供方发布服务到服务注册中心； 2)服务消费方从服务注册中心订阅服务； 3)服务消费方调用已经注册的可用服务； 1.2.核心功能 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。 1.3.Dubbo能做什么？ 透明化的远程方法调用：就像调用本地方法一样调用远程方法，只需简单配置，没有任何API 侵入。 软负载均衡及容错机制：可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 服务自动注册与发现：不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
分布式系统架构设计
本文作者Kate Matsudaira是一位美丽的女工程副总裁，曾在Sun Microsystems、微软、亚马逊这些一流的IT公司任职。她有着非常丰富的工作经验和团队管理经验，当过程序员、项目经理、产品经理以及人事经理。专注于构建和操作大型Web应用程序/网站，目前她的主要研究方向是SaaS（软件即服务）应用程序和云计算（如大家所说的大数据）。 本文是作者在AOSA一书介绍如何构建可扩展的分布式系统里的内容，在此翻译并分享给大家。 开源软件已经成为许多大型网站的基本组成部分，随着这些网站的逐步壮大，他们的网站架构和一些指导原则也开放在开发者们的面前，给予大家切实有用的指导和帮助。 这篇文章主要侧重于Web系统，并且也适用于其他分布式系统。 Web分布式系统设计的原则 构建并运营一个可伸缩的Web站点或应用程序到底是指什么？在最初，仅是通过互联网连接用户和访问远程资源。 和大多数事情一样，当构建一个Web服务时，需要提前抽出时间进行规划。了解大型网站创建背后的注意事项以及学会权衡，会给你带来更加明智的决策。下面是设计大型Web系统时，需要注意的一些核心原则： ?可用性 ?性能 ?可靠性 ?可扩展 ?易管理 ?成本 上面的这些原则给设计分布式Web架构提供了一定的基础和理论指导。然而，它们也可能彼此相左，例如实现这个目标的代价是牺牲成本。一个简单的例子：选择地址容量，仅通过添加更多的服务器（可伸缩性），这个可能以易管理（你不得不操作额外的服务器）和成本作为代价（服务器价格）。 无论你想设计哪种类型的Web应用程序，这些原则都是非常重要的，甚至这些原则之间也会互相羁绊，做好它们之间的权衡也非常重要。 基础
RSF 分布式服务框架设计
是时候设计一个分布式服务框架了。我先将它定名为Hasor-RSF，“RSF”为Remote Service Framework 的缩写。 RSF的目的是为了提供一种高效的远程服务访问方式，例如“A机器访问在B机器上的一个服务”。当然首先它是运行在Java上的，但是我并不希望Java 成为RSF的唯一平台。 它应该是分布式的，就是说服务 A 可能会分布在若干台机器内。当我的应用打算调用这个服务时我应该可以在这若干服务提供的机器上随机调用。这样做的好处是有助于高并发、高访问、高可用。 RSF 的本质其实就是RPC 那么我们可以先对比一下RPC 里都有什么可以被我们拿来选用。下面列出来的只是其中一些我相信聪明的朋友们会列举出更多的解决方案，我也敢保证你们知道的比我还多。 1.Java原生的 RMI。 2.Hessian 3.WebServices 4.Restful 5.HTTP Request 6.RTMP/AMF 7.淘宝的HSF、Dubbo
RMI，这个Java 原生的东东似乎从一开始就没有被人们所看好，究其原因是速度太慢。但是它的好处是Java原生，使用RMI 不需要引入其它任何第三方软件包。不过挑剔的同学们似乎不太看好这个优点。 Hessian，原则上说Hessian我并不认为它是一个远程服务框架范畴的东西。我更觉 得 Hessian 是一种数据交互格式。就像是JSON，XML-RPC，AMF，Kryo 一类的东西。Hessian 的优点是大量的兼容平台例如：“IOS、Java、.net、C++、Python、Flash、Ruby、PHP”，其次它的第二个有点是二进制格式。在大对象序列化上会占有很大的优势。 WebServices，一个老牌技术解决方案。在我印象中WebServices 是跟随着SOA 这个东西一起出名的，他有一个最大的好处是防火墙穿透。毕竟人家是靠80 端口吃饭的，牛叉的很。不过话说回来WebServices的最大要害就是，Xml传输格式。把一个对象序列化成为一个Xml数据是一件很容易的事，但是反序列化成本似乎是很高。再加上SOAP 协议本身是建立在XML 形式上，这就使得Web Service 奇慢无比了。当然因素还有很多我就不多说了。 Restful，其实restful 我更觉得它是一种API 表述规范。但在社区论坛中讨论看来，restful 的应用似乎也延伸到远程服务的领域。所以有必要说明一下。restful 最初是出现在web 上，究其本质是还是HTTP。例如对于：“http://xxxxx/xxxx”这个资源的访问可以利用HTTP 的“GET、PUT、DELETE”等方法对资源操作加以描述说明。我个人觉得这东西用在RPC 上并不合适。 HTTP，这是我用过最多的一种远程交互方式。远离很见dna，服务发布者将服务发布成为一个http资源。调用者请求这个http资源。数据传输格式完全程序双方自行协商。这种方法简单除暴行之有效。不过缺点是我们要自己补充通信协议，例如请求参数和响应数据格式。常规的交互格式有JSON、XML。
dubbo
DUBBO 1.Dubbo是什么? Dubbo是阿里巴巴开源的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。当我们的系统访问量和业务越来越大的时候，不可避免的需要拆分应用进行服务化，以提高开发效率，调优性能，节省关键竞争资源等。 其核心部分包含: 1. 远程通讯: 基于Netty NIO实现的长连接封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。 2. 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，无状态等。 3. 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以根据负载情况平滑增加或减少机器。 4.多种协议:dubbo对使用者很友好，可根据自己的习惯选择包括序列化协议(内置提供了dubbo，hessian2,java,json)，Transporter协议（内置支持mina，netty，grizzy），支持多种中间件做为注册中心（zookeeper，redis，multicast） 2. Dubbo能做什么? 1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入,对现有的代码几乎零改动。 2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 4.Dubbo对Spring做了Schema扩展支持，对于我们使用spring的项目来说灰常的方便，对应用的Api几乎是没有入侵的，只需要在spring中配置启动即可。
应用服务平台-分布式微服务应用平台建设方案
分布式微服务应用平台建设方案 1系统概述 1.1建设背景 世界正处于重大的技术变革之中，数字化正在主导经济的各个领域。在市场营销领域，数字消费者也日渐成熟，他们对于服务、速度和个性化的期待有了巨大转变，而这仅仅是个开始，因为互联网还在进化，万物相连已经不再停留在口上。 “互联网+”推动企业开始变革其产品、商业模式以及所有支持流程。企业需要开发新的IT系统，需要与其他伙伴协作互联的跨系统工作方式。需要实现IT系统支撑企业业务快速变化，需要支撑互联网应用特有的业务突发性、高并发、大容量。所以企业需要通过引入互联网技术提升IT系统的技术能力，帮助企业构建一个可以支撑企业业务快速交付、持续迭代、的基础业务PaaS平台，通过互联网微服务架构的共享服务建设模式，使业务数据积累和沉淀并形成资产，让数据说话成为可能，加速企业的数字化转型。 企业应用架构已经从SOA结构演进到微服务架构，倡导服务的细粒度、分布式、扩展性和治理能力。微服务在降低开发难度和提高系统扩展性的同时，往往也面临着工程管理、系统集成、服务治理以及部署运维等多方面的交付挑战。所以大家希望引入一个技术平台可以承载IaaS层所没有解决的微服务自动化管理问题。同时提供丰富的基础开发组件如：规则引擎、工作流、投递中心，以及企业外部的互联网能力如：消息推送、在线支付、邮件、短信、第三方平台等，可以在各个应用中复用和锤炼，以获得更高效的开发、更稳定的质量、更好业务契合度和更高的性能。 1.2建设目标 应用服务平台提供从开发、交付、运维监控一站式的平台解决方案，具体的建设目标如下： 1）构建完整的开发交付部署运维体系 应用服务平台以智能化和自动化为理念，通过持续集成、持续交付、自动化部署和
关于分布式服务框架Dubbo的调研报告
关于分布式服务框架Dubbo的调研报告 在接触过的项目中由于功能比较少，数据访问量并不是很大，在项目设计架构的时候总是优先考虑如何使代码简化，抽象相似方法。因此会引入诸如面向接口编程，面向切面编程，以及设计模式的考量。此时，ORM(Object/Relation Mapping)的数据访问框架，这种对象关系映射解决了面向对象与关系数据库存在的互不匹配的问题，也成了中小型项目基本的服务框架。其中，我了解的比较多的是显示层的struts2,数据持久层的Hibernate,以及业务逻辑层的Spring,三者通力配合可以大大简化应用服务的代码编程数量，可以让程序员在编写代码的时候优先考量功能需求，而不必为冗余的操作代码而浪费时间，其中我深有体会的有像将服务放入Spring,自动完成事物操作。还有关于CDUR的操作，数据存储与取得，只要进行简单的Hibernate配置就可以直接实现关系对象的转化。 当然以上ORM框架的核心以及它所完成的任务决定了一个项目分层架构是一种垂直纵向的关系，比如说我们经典的MVC模式，我们需要实体层，数据持久层，业务逻辑层，以及显示层。持久层，业务逻辑层，显示层在设计的时候需要从上往下传递数据对象，因而考量设计的重点在于高内聚，低耦合。层与层之间要相互依赖，又要相互独立。这样的设计在进行功能量适中，访问服务数量不多的情况能够应对自如，但是当访问服务数量激增，系统功能变得复杂的时候这种基于ORM的服务架构就会显得笨重，并且不利于测试。 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变得市场需求。那么，提高业务复用及整合的分布式服务框架RPC（Remote Procedure Call Protocol）就成了关键。 这种抽取核心功能的方式非常类似于MVC模型下模板方法模式，即抽取公共方法为抽象基类，而在此处就将相似服务功能抽取出来形成注册服务中心来统一调配资源。 Duboo就是这种分布式服务框架，它主要针对的是一种SOA方案，我们知道面向对象模型是紧耦合的，而SOA指得就是一种面向服务体系，实际上就是我们都认知的面向接口编程，这也是分布式核心思想，尽量用接口定义公共服务
分布式架构知识体系
1.问题 1、何为分布式何为微服务？ 2、为什么需要分布式？ 3、分布式核心理论基础，节点、网络、时间、顺序，一致性？ 4、分布式是系统有哪些设计模式？ 5、分布式有哪些类型？ 6、如何实现分布式？ 2.关键词 节点，时间，一致性，CAP，ACID，BASE，P2P，机器伸缩，网络变更，负载均衡，限流，鉴权，服务发现，服务编排，降级，熔断，幂等，分库分表，分片分区，自动运维，容错处理，全栈监控，故障恢复，性能调优 3.全文概要 随着移动互联网的发展智能终端的普及，计算机系统早就从单机独立工作过渡到多机器协作工作。计算机以集群的方式存在，按照分布式理论的指导构建出庞大复杂的应用服务，也已经深入人心。本文力求从分布式基础理论，架构设计模式，工程应用，部署运维，业界方案这几大方面，介绍基于MSA(微服务架构)的分布式的知识体系大纲。从而对SOA 到MSA进化有个立体的认识，从概念上和工具应用上更近一步了解微服务分布式的本质，身临其境的感受如何搭建全套微服务架构的过程。
4.基础理论 4.1SOA到MSA的进化 SOA面向服务架构 由于业务发展到一定层度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯，面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障的时候会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。 MSA微服务架构
微服务是真正意义上的独立服务，从服务入口到数据持久层，逻辑上都是独立隔离的，无需服务总线来接入，但同时增加了整个分布式系统的搭建和管理难度，需要对服务进行编排和管理，所以伴随着微服务的兴起，微服务生态的整套技术栈也需要无缝接入，才能支撑起微服务的治理理念。 4.2节点与网络 节点 传统的节点也就是一台单体的物理机，所有的服务都揉进去包括服务和数据库；随着虚拟化的发展，单台物理机往往可以分成多台虚拟机，实现资源利用的最大化，节点的概念也变成单台虚拟机上面服务；近几年
dubbo文档
Dubbo开发指南 一、Dubbo介绍 1、Dubbo是什么？能做什么？ Dubbo是一个分布式服务框架，以及SOA治理方案。其功能主要包括：高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。 2、Dubbo适用于哪些场景？ 当网站变大后，不可避免的需要拆分应用进行服务化，以提高开发效率，调优性能，节省关键竞争资源等。 当服务越来越多时，服务的URL地址信息就会爆炸式增长，配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？等等…… 在遇到这些问题时，都可以用Dubbo来解决。 二、Dubbo架构
节点角色说明： ?Provider:暴露服务的服务提供方。 ?Consumer:调用远程服务的服务消费方。 ?Registry:服务注册与发现的注册中心。 ?Monitor:统计服务的调用次调和调用时间的监控中心。 ?Container:服务运行容器。 调用关系说明： ?0. 服务容器负责启动，加载，运行服务提供者。 ? 1. 服务提供者在启动时，向注册中心注册自己提供的服务。 ? 2. 服务消费者在启动时，向注册中心订阅自己所需的服务。 ? 3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 ? 4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 ? 5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。 (1) 连通性： ?注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小 ?监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示 ?服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销 ?服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销 ?注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外 ?注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者 ?注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表 ?注册中心和监控中心都是可选的，服务消费者可以直连服务提供者 (2) 健状性： ?监控中心宕掉不影响使用，只是丢失部分采样数据 ?数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务 ?注册中心对等集群，任意一台宕掉后，将自动切换到另一台 ?注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯 ?服务提供者无状态，任意一台宕掉后，不影响使用 ?服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
分布式服务框架 Zookeeper -- 管理分布式环境中的数据
安装和配置详解 本文介绍的Zookeeper 是以3.2.2 这个稳定版本为基础，最新的版本可以通过官 网https://www.360docs.net/doc/f42432927.html,/zookeeper/来获取，Zookeeper 的安装非常简单，下面将从单机模式和集群模式两个方面介绍Zookeeper 的安装和配置。 单机模式 单机安装非常简单，只要获取到Zookeeper 的压缩包并解压到某个目录如： /home/zookeeper-3.2.2 下，Zookeeper 的启动脚本在bin 目录下，Linux 下的启动脚本是zkServer.sh，在3.2.2 这个版本Zookeeper 没有提供windows 下的启动脚本，所以要想在windows 下启动Zookeeper 要自己手工写一个，如清单1 所示： 清单1. Windows 下Zookeeper 启动脚本 在你执行启动脚本之前，还有几个基本的配置项需要配置一下，Zookeeper 的配置文件在conf 目录下，这个目录下有zoo_sample.cfg 和log4j.properties，你需要做的就是将zoo_sample.cfg 改名为zoo.cfg，因为Zookeeper 在启动时会找这个文件作为默认配置文件。下面详细介绍一下，这个配置文件中各个配置项的意义。 tickTime：这个时间是作为Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime 时间就会发送一个心跳。
?dataDir：顾名思义就是Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。 ?clientPort：这个端口就是客户端连接Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。 当这些配置项配置好后，你现在就可以启动Zookeeper 了，启动后要检查Zookeeper 是否已经在服务，可以通过netstat – ano 命令查看是否有你配置的clientPort 端口号在监听服务。 集群模式 Zookeeper 不仅可以单机提供服务，同时也支持多机组成集群来提供服务。实际上Zookeeper 还支持另外一种伪集群的方式，也就是可以在一台物理机上运行多个Zookeeper 实例，下面将介绍集群模式的安装和配置。 Zookeeper 的集群模式的安装和配置也不是很复杂，所要做的就是增加几个配置项。集群模式除了上面的三个配置项还要增加下面几个配置项： ?initLimit：这个配置项是用来配置Zookeeper 接受客户端（这里所说的客户端不是用户连接Zookeeper 服务器的客户端，而是Zookeeper 服务器集群中连接到 Leader 的Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过10 个心跳的时间（也就是tickTime）长度后Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒 ?syncLimit：这个配置项标识Leader 与Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个tickTime 的时间长度，总的时间长度就是2*2000=4 秒?server.A=B：C：D：其中A 是一个数字，表示这个是第几号服务器；B 是这个服务器的ip 地址；C 表示的是这个服务器与集群中的Leader 服务器交换信息的端口；D 表示的是万一集群中的Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于B 都是一样，所以不同的Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号。 除了修改zoo.cfg 配置文件，集群模式下还要配置一个文件myid，这个文件在dataDir 目录下，这个文件里面就有一个数据就是A 的值，Zookeeper 启动时会读取这个文件，拿到里面的数据与zoo.cfg 里面的配置信息比较从而判断到底是那个server。 数据模型 Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统，如图1 所示：
分布式服务框架 Zookeeper -- 管理分布式环境中的数据
分布式服务框架Zookeeper -- 管理分布式环境中的数据 简介：Zookeeper 分布式服务框架是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。本文将从使用者角度详细介绍Zookeeper 的安装和配置文件中各个配置项的意义，以及分析Zookeeper 的典型的应用场景（配置文件的管理、集群管理、同步锁、Leader 选举、队列管理等），用Java 实现它们并给出示例代码。 安装和配置详解 本文介绍的Zookeeper 是以3.2.2 这个稳定版本为基础，最新的版本可以通过官 网https://www.360docs.net/doc/f42432927.html,/zookeeper/来获取，Zookeeper 的安装非常简单，下面将从单机模式和集群模式两个方面介绍Zookeeper 的安装和配置。 单机模式 单机安装非常简单，只要获取到Zookeeper 的压缩包并解压到某个目录如： /home/zookeeper-3.2.2 下，Zookeeper 的启动脚本在bin 目录下，Linux 下的启动脚本是zkServer.sh，在3.2.2 这个版本Zookeeper 没有提供windows 下的启动脚本，所以要想在windows 下启动Zookeeper 要自己手工写一个，如清单1 所示： 清单1. Windows 下Zookeeper 启动脚本 在你执行启动脚本之前，还有几个基本的配置项需要配置一下，Zookeeper 的配置文件在conf 目录下，这个目录下有zoo_sample.cfg 和log4j.properties，你需要做的就是将 zoo_sample.cfg 改名为zoo.cfg，因为Zookeeper 在启动时会找这个文件作为默认配置文件。下面详细介绍一下，这个配置文件中各个配置项的意义。
springMVC+Spring+Mybatis+dubbo分布式框架的详细搭建与讲解
SSM+dubbo分布式框架的详细搭建与讲解 一、什么是dubbo？ 两台服务器A、B，分别部署不同的应用a,b。当A服务器想要调用B服务器上应用b提供的函数或方法的时候，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义传达调用的数据。--RPC。 Dubbo是基于RPC的高性能和透明化的RPC远程服务调用方案。 二、为什么使用dubbo? Dubbo原理有点类似以前tomcat集群，不过与tomcat集群比起来dubbo优势在于：一次编译，到处运行。 三、系统框架如下： 四、框架内容：SpringMVC+Spring+Mybatis+Mysql+JDK1.7数据库使用的是 mysql，安装步骤省略 五、项目工程结构目录（父工程和子工程） 其中，parent是pom文件的父工程，common是jar包，里面存放interface，bean，dao等公用内容。
controller控制层和service业务层是war包,也就是各分为一个Tomcat。A:创建父工程
B：创建common工程,在Packaging时选择jar
C：创建controller和service的步骤和common一样,不过Packaging选择war，完成后会出现以下报错 原因是webapp下没有WEB_INF文件夹和web.xml文件，自己创建web.xml(配置内容下面会有) D：导入JAR包 parent项目pom.xml导入所有jar包的坐标，service和controller会依赖common,所以在common的pom文件中加入要引入的jar包。因为太多，此处省略，到时候可以看源码 因为公用jar放在了common里，所以在controller和service的pom,xml文件中都加入common的依赖：
Dubbo服务环境搭建说明
dubbo服务环境搭建说明 简介： dubbo是alibaba开源的分布式服务框架，它包含服务调用者、服务提供者、负载均衡和服务治理等。负载均衡和服务治理dubbo做了高度封装，开发者只需要关心服务的调用和提供就行。 项目架构： dubbo的项目开发架构主要包括：dubbo API、domain POJO、dubbo provider、dubbo customer（dubbo customer一般通过xml配置在调用端就可以，不需要单独创建为一个项目）。 搭建一个独立dubbo服务的时候，最少需要创建三个项目 1、api接口项目： 用于声明dubbo服务提供的接口。 2、domain 项目： 用于创建dubbo远程传输的Java POJO。 每一个POJO都必须实现Serializable序列化接口 3、provider项目： dubbo的服务提供server，是api中声明的接口的实现。 如果项目太大或者模块化分得更细，可以把provider拆分出service和dao等。 项目搭建说明： 1、项目统一命名规则： egolm-<项目名称>-<模块名称> 2、项目包名规则： com.egolm.<项目名称>.<模块名称>.<功能名称>.<自定义扩展...> 3、api和domain是普通的Java项目，消费者和生产者都需要依赖api和domain，api 和domain是普通项目，不需要进行任何配置，每一个provider中，需要有api接口的实现 api项目结构: src/main/java Domain项目结构： src/main/java 4、provider项目结构(provider和其拆分模块适用)： src/main/java src/main/resources src/test/java src/test/resources src/main/resources下的spring-xml文件命名规则包括 <项目名称>-<模块名称>-
EDAS比DUBBO强在哪里
EDAS与dubbo有什么不一样？ 1总体来讲： ?EDAS是一个以应用为中心的PAAS平台，而dubbo只是一个RPC框架,只是一个EDAS 很小的一个子集 ?对于大规模分布式系统，如何比较科学有效率的管理百个以上的应用 ?对于服务调用的权限控制，我们开源的dubbo是没有的 ?对于应用的实时监控，以及全链路监控，开源的dubbo更是不具备 ?对于应用管理的权限，EDAS支持主子帐号，不同的人，拥有不同的权限，管理不同的 应用 ?在EDAS的未来产品规划中，分布式应用的配置推送，灰度发布能力，业务监控，全息 排查等，跟dubbo无所谓区别的问题，是这些能力远远超越了一个RPC框架的范围。 2具体来讲： Dubbo和企业互联网架构EDAS中的HSF产品进行对比分析。 1)Dubbo Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。 2)EDAS EDAS（企业级分布式应用服务，Enterprise Distributed Application Service）是一个以阿里巴巴中间件团队的多款久经沙场的分布式产品作为核心基础组件构建的企业云计算解决方案，其充分利用阿里云IAAS资源，引入中间件整套成熟的分布式计算框架（包括分布式服务化框架、统一的会话框架，链路追踪和稳定性组件等），以应用为中心，帮助企业级客户轻松构建大型分布式应用服务。 EDAS是阿里企业互联网架构解决方案中分布式服务的解决方案。 它主要提供的功能有： 1.应用开发服务生命周期管理 2.实时日志 3.容器诊断
Dubbo面试及答案(上).
Dubbo 支持哪些协议，每种协议的应用场景，优缺点？ dubbo：单一长连接和NIO 异步通讯，适合大并发小数据量的服务调用， 以及消费者远大于提供者。传输协议TCP，异步，Hessian 序列化； rmi：采用JDK 标准的rmi 协议实现，传输参数和返回参数对象需要实现 Serializable 接口，使用java 标准序列化机制，使用阻塞式短连接，传输数 据包大小混合，消费者和提供者个数差不多，可传文件，传输协议TCP。 多个短连接，TCP 协议传输，同步传输，适用常规的远程服务调用和rmi 互 操作。在依赖低版本的Common-Collections 包，java 序列化存在安全漏洞； webservice：基于WebService 的远程调用协议，集成CXF 实现，提供和 原生WebService 的互操作。多个短连接，基于HTTP 传输，同步传输，适 用系统集成和跨语言调用； http：基于Http 表单提交的远程调用协议，使用Spring 的HttpInvoke 实 现。多个短连接，传输协议HTTP，传入参数大小混合，提供者个数多于消 费者，需要给应用程序和浏览器JS 调用； hessian：集成Hessian 服务，基于HTTP 通讯，采用Servlet 暴露服务， Dubbo 内嵌Jetty 作为服务器时默认实现，提供与Hession 服务互操作。多 个短连接，同步HTTP 传输，Hessian 序列化，传入参数较大，提供者大于 消费者，提供者压力较大，可传文件； memcache：基于memcached 实现的RPC 协议 redis：基于redis 实现的RPC 协议 Dubbo 超时时间怎样设置？ Dubbo 超时时间设置有两种方式： 服务提供者端设置超时时间，在Dubbo 的用户文档中，推荐如果能在服务 端多配置就尽量多配置，因为服务提供者比消费者更清楚自己提供的服务特 性。 服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端 为主，即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消 费方超时，服务端线程不会定制，会产生警告。 Dubbo 有些哪些注册中心？ Multicast 注册中心：Multicast 注册中心不需要任何中心节点，只要广播地 址，就能进行服务注册和发现。基于网络中组播传输实现； Zookeeper 注册中心：基于分布式协调系统Zookeeper 实现，采用 Zookeeper 的watch 机制实现数据变更； redis 注册中心：基于redis 实现，采用key/Map 存储，住key 存储服务名 和类型，Map 中key 存储服务URL，value 服务过期时间。基于redis 的发 布/订阅模式通知数据变更； Simple 注册中心 Dubbo 集群的负载均衡有哪些策略