RSF 分布式服务框架设计
分布式架构服务方案范本
分布式架构服务方案范本分布式架构服务方案范本一、方案背景随着互联网的发展，用户规模和访问量的增加，传统的单一服务器架构已经无法满足业务需求。
为了提升系统的可用性、扩展性和容错性，我们决定采用分布式架构来重新设计我们的服务系统。
二、目标1. 提高系统的可用性和可扩展性，确保系统能够持续稳定运行。
2. 提升系统的容错性，避免单点故障导致的系统宕机。
3. 支持快速部署和灵活扩展，适应业务发展和用户规模的变化。
4. 提升系统的性能和响应速度，提供更好的用户体验。
三、架构设计1. 业务拆分：将系统按照不同的业务功能进行拆分，每个业务功能作为一个独立的服务模块进行开发和部署。
2. 服务注册与发现：采用服务注册与发现机制，每个服务模块在启动时注册自己的信息，并通过发现服务来查找其他服务。
3. 负载均衡：引入负载均衡器，对请求进行分发，使得请求能够平均分配到每个服务实例上，提高系统的并发处理能力。
4. 分布式缓存：采用分布式缓存来提升系统的读取速度和响应速度，减少对数据库的访问压力。
5. 数据库设计：将原有的单一数据库拆分成多个数据库，根据不同的业务功能将数据分散存储，提高数据库的读写性能。
6. 高可用设计：引入主从复制和故障转移机制，确保系统在发生故障时能够自动切换到备用节点上，保证服务的持续可用性。
7. 异步处理：采用消息队列的方式对一些耗时操作进行异步处理，提高系统的并发能力和响应速度。
8. 监控与告警：引入监控与告警系统，对系统进行实时监控，及时发现并处理系统异常情况。
四、实施计划1. 梳理系统架构，确定拆分业务功能和服务模块。
2. 实现服务注册与发现机制，建立服务注册中心。
3. 引入负载均衡器，并进行性能测试和压力测试。
4. 设计和实现分布式缓存方案，提升系统的读取速度和响应速度。
5. 对数据库进行拆分和优化，提高数据库的读写性能。
6. 设计和实现高可用方案，确保系统的持续可用性。
7. 引入消息队列，设计和实现异步处理方案。
DSF分布式服务框架设计
1
List对象序列化样例:
List typeid 589 List size 2 typeid length element1 element2
sortid=1 sortid=2 Int num; Int age;
sortid=1 sortid=2 sortid=3 typeid length Int num; Int age; String name;
DSF分布式服务框架设计
技术创新，变革未来
目录
DSF产生背景
DSF介绍
服务治理实践
背景
统一服务框架
多服务框架：58同城RPC框架、Dubbo框架、…… 维护成本高
统一服务治理
注册中心、C框架核心流程
Client
RetObj retObj=proxy.fun(a, b)
DSF介绍
跨语言、跨平台
客户端 Java C & C++ 服务端(Java DSF容器) TCP长连接 DSF序列化
客户端
DSF序列化 DSF协议
客户端
DSF序列化 DSF协议
DSF协议
客户端、服务端，使用相同的序列化和协议
DSF介绍
高可用
服务多节点部署 健康检查 过载丢弃(请求阈值) 服务平滑重启 降级处理 客户端重试机制&故障转移 客户端超时处理
Cache-Client
traceid:”unique_id” spanId:”0.1.1.1"
DB-tool访问表1
traceid:”unique_id” spanId:”0.1.1.2"
DB-tool访问表2
traceid:”unique_id” spanId:”0.1.1.3"
RSF分布式RPC服务框架的分层设计
RSF分布式RPC服务框架的分层设计RSF 是个什么东西？⼀个⾼可⽤、⾼性能、轻量级的分布式服务框架。
⽀持容灾、负载均衡、集群。
⼀个典型的应⽤场景是，将同⼀个服务部署在多个Server 上提供 request、response 消息通知。
使⽤RSF可以点对点调⽤，也可以分布式调⽤。
部署⽅式上：可以搭配注册中⼼，也可以独⽴使⽤。
渊源RSF 的核⼼思想参考了淘宝HSF、Dubbo 等优秀框架。
功能上⼤体相似，但是实现逻辑完全不同。
因此没有什么历史包袱。
总的来说对⽐淘宝HSF少了历史包袱，相⽐Dubbo更加轻量化。
⽽且还⽀持了虚拟机房，对于多机房部署的产品可以省下⼤量带宽成本，同时也降低了远程调⽤时间。
RSF虽然在功能上与两位前辈出⼊不⼤，使⽤RSF最直观的感受就是简单⽅便，配置少、依赖少，功能强⼤。
特点RSF 的最⼤特点就是在强⼤的功能⽀持下，依然可以保持：最简单、最轻量。
我们先轻描淡写的说⼀下RSF 的特点。
简单容易（三个⼀）：1 ⾏代码发布服务、1 ⾏代码订阅服务、1 ⾏代码使⽤服务体积轻薄：RSF 是基于 Hasor 构建，此外还依赖了 netty 和 groovy。
因此包含 RSF 在内引⼊的JAR包总数只有 5 个，其中 RSF 只有⼤约 700KB 的体积。
⼯作原理RSF 是专门为集群、⾼可⽤系统进⾏设计的分布式 RPC 服务框架。
服务提供者可以是⼀个集群，服务的消费者也可以是⼀个集群，两者混合在⼀个集群⾥也是ok的。
同时为了增强融灾 RSF 的注册中⼼也是⽀持集群的。
所以基于 RSF 构建的服务系统不会存在任何单点问题。
框架分层RSF 的架构设计上遵循了⾃顶⽽下明确的分层设计，每⼀层都有专注的⼯作职责。
⼤体分为 9 个层次。
他们如下所⽰：，你也可以理解这是 RSF 的架构设计。
第⼀层：是业务系统中的服务，⼀个服务的状态可以是提供者(Provider)、也可以是消费者(Customer)，或者两者共存。
分布式服务框架设计要点-03
原创|分布式服务框架设计要点（续）----------本节内容-------1. 服务调用2. 服务注册中心3. 服务发布和引用4. 灰度发布5. 服务多版本管理6. 流量控制7. 参考资料--------------------------随着业务的发展，应用规模不断扩大，系统内部的巨无霸应用越来越多，常规的垂直应用架构已经无法应对复杂业务带来的各种挑战，通过将业务功能能力抽象成原子服务，对复杂应用进行水平的拆分和服务化，实现服务消费者和提供者的解耦，这就是分布式服务框架要干的活。
1.服务降级服务降级，当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行屏蔽降级2.服务注册中心服务的提供者和消费者，就像2个互相提防的生意人，不能直接接头，但是又得把生意做好。
这个时候怎么办，需要一个服务贩子（中间人）。
通过服务贩子（中间人）来传话，或者服务提供者把服务“卖”给了消费者，有时服务提供者也会从其他服务提供者“买”服务。
服务贩子界，最出名的要数ZooKeeper了。
3.服务发布和引用服务发布，用开发人员比较容易理解的的话就是别人怎么用你开发好的类、方法，最容易理解的方法就是拿个类过来直接new 对象出来，然后通过对象来调用方法，这个是比较简单且粗暴的，还有一些如利用反射机制、代理来调用方法。
我们自己开发自己用比较简单，自己开发别人用，就存在环境不同、工程不同等障碍，用起来也不那么容易。
4.灰度发布灰度发布时是指在黑与白之间，能平滑过渡的一种发布方式，AB test 就是一种灰度发布方式：让一部分用户继续用A，一部分用户开始用B，如果永华对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
为什么要有灰度发布？在互联网公司的朋友们应该深有感触：产品不停的升级、升级再升级，而且服务不能下线，还不能对用户有太大的影响，这个场景用灰度发布就特别适合，总结起来，灰度发布有如下好处：1）解决服务升级不兼容的问题；2）及早获得用户的意见反馈，尽快完善产品功能；3）缩小服务升级所影响的用户范围，降低升级风险；4）让用户及早参与产品测试，加强用户互动。
分布式系统的架构设计指南
分布式系统的架构设计指南在当今信息技术发展迅猛的时代，分布式系统已经变得非常普遍和重要。
它们可以将计算和存储资源分散到多个节点上，以提高性能、可靠性和可扩展性。
分布式系统的架构设计是确保系统在满足需求的同时，能够高效地运行的关键。
在本文中，我们将提供一些关于分布式系统架构设计的指南。
1. 选择合适的架构模式在设计分布式系统时，选择合适的架构模式非常重要。
常见的架构模式包括客户端-服务器模式、代理模式、发布-订阅模式等。
不同的模式适用于不同的应用场景。
例如，当需要处理大量请求时，客户端-服务器模式是一个不错的选择。
而当需要实现实时更新时，发布-订阅模式则更合适。
2. 划分模块和组件将系统划分为模块和组件有助于提高系统的可维护性和可扩展性。
每个模块和组件应该有明确的功能和职责，并且彼此之间的关系应该清晰可见。
在划分模块和组件时，需要考虑系统的需求和架构模式的选择。
3. 考虑性能与可靠性性能和可靠性是分布式系统设计中需要重点关注的两个方面。
在设计系统时，需要考虑到系统的负载、数据传输速率以及系统的容错能力。
合理的负载均衡、数据缓存和故障恢复机制都是提高系统性能和可靠性的关键。
4. 选择适当的通信协议分布式系统中的节点进行通信是必不可少的。
选择适当的通信协议对于系统的性能和可拓展性至关重要。
常见的通信协议包括HTTP、TCP/IP、MQTT等。
不同的协议有不同的特点和适用场景，需要根据系统的需求进行选择。
5. 数据管理与同步在分布式系统中，数据管理和同步是一个重要的考虑因素。
设计合理的数据管理策略可以保证数据的一致性和可靠性。
采用分布式数据库、备份和复制策略可以防止数据丢失和系统故障。
6. 安全性与权限控制在设计分布式系统时，安全性和权限控制是非常重要的。
合理的安全策略可以保护系统免受安全威胁和恶意攻击。
采用合适的身份验证和权限控制机制可以确保系统的数据和资源只能被授权的用户访问。
7. 考虑系统扩展性系统的扩展性是保证系统在需求增长时能够快速适应变化的关键。
RSF远程服务调用框架介绍
RSF远程服务调用框架介绍苏宁的系统间交互最初使用中心化ESB 架构，但随着系统拆分工作的展开及业务量的迅速攀升，系统间调用规模越来越大，ESB 中心化架构带来的诸如中心资源隔离、中心容量动态评估、问题排查难度、中心化扩展能力瓶颈等问题迅速显现。
并且，随着自研系统逐步替换商用系统，需要进行协议转换等工作逐步弱化，因此苏宁亟待一个更轻量化的去中心化的跨系统服务调用方案。
苏宁远程服务框架（RSF）致力于解决系统间的服务调用问题，提供一种透明的、高性能的RPC 服务调用方案。
目前应用于苏宁1000+ 系统，每天的服务调用次数在200 亿左右，是苏宁使用最广泛的技术组件。
开源世界里成熟的RPC 比较多，简单的如spring remoting，应用广泛，短短几行代码及配置就可以实现跨系统方法调用，但是都只是止步于调通服务。
对于一个由上千个系统协同交互构成的复杂电商交易平台来说，只是达到跨系统能调通是远远不够的，需要考虑的问题有很多，比如服务节点的动态注册和发现，生产问题的快速干预，服务治理等等。
而在不同的环境、背景下，也会有各自的需求和挑战，这也正是我们选择构建自己的RPC 框架的核心原因。
本文将重点介绍RSF 的重点特性及一些我们面临的挑战和相应的解决方案。
重点特性1. 同步、异步Future、异步Callback 三种调用模型同步调用：是最普遍使用的形式，使用同步调用，当前调用线程会阻塞等待服务调用返回结果或抛出异常。
异步future：调用立刻返回，当前线程不会阻塞，不会等待服务提供方执行完成。
服务提供方的返回结果可以后续通过Future get 来获得，这种调用形式在某些场景下会特别有用，能实现并行调用服务。
Future get 会阻塞当前线程，直到服务方返回结果或有异常抛出。
异步Callback：调用立刻返回，当前线程不会阻塞，不会等待服务提供方执行完成。
当服务方返回结果或抛出异常时，异步执行callback 中相应的方法。
分布式服务架构原理设计与实战
分布式服务架构原理设计与实战分布式服务架构是一种将系统的功能性和可伸缩性分解为多个独立的服务单元，并通过网络进行通信和协同工作的架构模式。
它可以帮助我们构建高可用性、高性能、可扩展的系统，同时也可以提高开发的灵活性和团队的协作效率。
本文将从原理、设计和实战三个方面详细介绍分布式服务架构。
首先，我们来看一下分布式服务架构的原理。
分布式服务架构的核心原理是将一个复杂的系统拆分为多个独立的服务单元，每个服务单元负责一个特定的业务功能。
这些服务单元之间通过网络进行通信和协作，可以通过消息传递、远程调用等方式进行交互。
通过将系统拆分成独立的服务单元，可以提高系统的可伸缩性和容错性，使系统更加灵活和可扩展。
其次，我们来看一下分布式服务架构的设计。
在设计分布式服务架构时，需要考虑以下几个方面。
首先是服务的边界划分，即将系统拆分为哪些独立的服务单元。
这需要根据业务需求和系统的复杂性进行合理的划分，避免服务单元之间的依赖过于紧密。
其次是服务的接口设计，即定义服务单元之间的通信接口。
接口设计要简洁明确，避免过于复杂和冗余。
同时，还需要考虑服务的部署和扩展方式，以及服务的监控和调试手段。
最后，我们来看一下分布式服务架构的实战。
在实际应用中，可以采用一些成熟的分布式服务框架，如Spring Cloud、Dubbo等。
这些框架提供了一系列的工具和组件，可以方便地构建和管理分布式服务。
此外，还可以采用一些常用的设计模式，如服务注册与发现、负载均衡、熔断器等，来增加系统的稳定性和可靠性。
同时，还需要考虑一些分布式系统的挑战，如数据一致性、并发控制等问题，采用合适的解决方案来解决这些问题。
总结起来，分布式服务架构是一种将系统拆分为多个独立的服务单元，并通过网络进行通信和协同工作的架构模式。
它可以提高系统的可伸缩性、可用性和灵活性。
在设计和实施分布式服务架构时，需要考虑服务的边界划分、接口设计、部署和扩展方式等方面，并采用合适的分布式服务框架和设计模式来提高系统的稳定性和可靠性。
如何进行分布式系统架构设计
如何进行分布式系统架构设计在当今互联网时代，随着大数据和云计算的崛起，分布式系统架构设计越来越成为互联网应用领域的主流趋势。
分布式系统架构设计的核心目标在于提高系统的可靠性、可伸缩性和可维护性。
一、概述随着数据量的不断增加，单一系统已经无法承载大规模的数据处理需求。
为了提高系统的处理能力和可靠性，分布式系统应运而生。
在分布式系统中，不同的计算资源被分布在多个计算节点之上，形成了一个协同工作的整体系统。
因此，分布式系统架构设计需要兼顾系统结构和实现方式两个方面。
二、分布式系统结构设计原则1. 服务分类和分层在分布式系统中，通常将系统中的服务按照功能划分为不同的服务分类。
不同的服务之间可以根据实际需要进行不同的部署和管理。
同时，可以通过分层来实现系统的各个服务之间的上下游功能调用。
2. 模块化设计在分布式系统中，系统的各个服务在功能上可以进行细分，每个细分功能模块可以独立的运行和部署。
这样，可以让系统更加模块化，架构更加清晰。
3. 异步化设计在分布式系统中，由于各个服务之间的通信以及数据的传输，通常需要较长的时延。
因此，在系统设计上可以采用异步化的方案，减少系统响应时间，提升系统的处理能力。
三、分布式系统实现方式1. 服务端框架服务端框架可以帮助我们快速搭建分布式系统，例如：Dubbo、Spring Cloud、Apache Thrift等。
这些框架提供了完善的服务化治理方案，可以通过框架来完成服务发布和服务的管理。
2. 消息中间件消息中间件是分布式系统实现的一种重要方式，通过消息中间件，可以实现分布式系统之间的异步通信。
目前业界比较主流的消息中间件有：Apache Kafka、RabbitMQ等。
3. 分布式存储分布式系统离不开分布式存储。
分布式存储可以通过对象存储、分布式文件系统、键值存储等多种方式实现。
常见的分布式存储方案有：Hadoop HDFS、Ceph、GlusterFS、MongoDB等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
是时候设计一个分布式服务框架了。
我先将它定名为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。
RTMP/AMF，这个组合的确是一套很完善的远程调用解决方案。
RTMP协议中专门为Invoke 开辟了一条通道，在配合AMF 格式极大的方便了Flash 下远程服务访问。
不过这些都是Flash下的东西，即使是拥有Red5 这样的神器让我们在java 下可以使用rtmp 但是究其目的还是为了和flash 通信。
一般flash 调用业务系统的方式还都停留在http 请求或者通过red5 服务器代为转发。
HSF，这个东西是淘宝内部用的很广泛的远程服务框架。
它是使用NIO、Mina 并且工作在长连接模式下。
话说这个东西的确是个好东西，淘宝也将其开源了！只可惜，开源了hsf 但是相关配套依赖没有开源。
在加上hsf 依赖繁杂。
这个东西也就只能让局外人膜拜一下，在淘系之外的同学们是无福享受了。
Dubbo，也是淘系的另外一个服务框架，它比较HSF 来说要轻巧很多。
依赖会少一些，这个东东目前也是开源状态。
由于我对 dubbo 一点都不了解，在这里保持沉默不做评价。
最后补充一下，真正原生就支持分布式服务调用的也就只有“HSF、Dubbo”至于京东内部是否有更好的解决方案我并不知道。
哦还有一点，如果您想脱离Spring 的话HSF、Dubbo 会让你失望的。
这就是说您的技术构架如果是非Spring 阵营的会比较悲催。
so，上面提到了很多可用的技术方案，想必最后符合要求也就只有其中HSF 和Dubbo 了。
为什么其它的方案都不入选呢？原因就是它们虽然可以完成RPC 但是并不支持分布式。
当然您可以通过架设集群来提高它们的可靠性，这些都是您需要额外付出的。
------------------------------
下面这个是RSF 的架构图，包括服务生产着和消费者在内RSF 被分为 6 层（网络层、协议层、请求响应层、调度层、接口层、消费者生产者）。
关键5层：
Netty，其中位于最下层的网通信部分RSF 采用Netty 实现。
Netty 是一款非常优秀的网络通信框架，使用Netty 可以帮助RSF 减少大量底层网络上的代码开发。
这也就意味着RSF 将采用 Selector 方式实现异步IO。
Protocol，协议层。
该层主要的目的是负责解释翻译RSF 数据包，并将RSF 数据包转意成为Request 和Response 对象。
协议层可以是一个协议栈，这就意味您可以通过RTMP 、或者其它自定义网络协议传输RSF 数据包。
Request/Response层，请求响应层。
这个在这个层中，RSF 脱离了底层网络方面的特性将每次调用请求对象化为一个Request 对象，并且将调用结果封装成为一个Response 对象。
这种编程模式和Web 很像。
调度层，这一层最为复杂。
它负责管理本地RSF 服务的注册，远程传输对象序列化方式的管理，并且还要负责实现其它更加复杂的功能。
接口层，这一层是最终RSF 暴露给业务系统的接口，将会由两个类提供。
一个代表服务生产着，另一个是服务消费者。
序列化格式：
RSF 规定在网络中传输的数据格式可以是任意的。
这就意味着您可以使用AMF 作为RSF 数据传输格式发布（同时如果协议层支持RTMP 那您可以在Flash 中无需通过red5 这样的中间代理直接访问RSF 服务）。
同样的，如果您使用 Hessian 作为数据传输格式，在其它平台。
例如.net、php。
也会很方便的调用RSF 服务（需要解析RSF 数据包）。
如果协议采用HTTP，RSF序列化格式采用JSON ，那么运行在浏览器中的javascript 也可以绕过web 服务器，直接访问RSF 服务。
服务配置Config：
说是服务配置，其实就是路由的功能。
先假设我们有4台服务器，其中有两台是位于北京机房，另外两台分别位于青岛和内蒙古。
这四台机器上都运行着RSF，跑着相同的业务系统，这种架构通常前端会有一个CDN 之类的东西负责让用户就近访问网站。
如果没有服务路由的情况下，用户A在北京即使访问了最近的北京服务器，但是由于调用的RDS 服务是青岛的，那么也会降低访问速度。
因此服务配置所负责的路由特性可以很方便的高速服务调用程序，优先选用北京机房的RSF 服务。
只有当北京机房的服务撑不住的情况下才会动用其它地域的RSF 服务。
流量管控：高级一点的特性是可以通过服务路由来控制服务流量。
假如目前要做一个全国范围的活动，我们充分的为每个地方准备了若干机器。
但是在活动现场很可能某一个地区的服务使用量达到了临界点，服务路由应该可以通过配置的方式让附近地区的机器提供一定的流量来减缓这个地区的访问压力。