第三方登录：后使用快捷导航没有帐号？
查看: 2120|回复: 6
Java分布式应用技术架构介绍 【引用】
中级会员, 积分 373, 距离下一级还需 127 积分
论坛徽章:3
多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。
使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。系统架构演化历程-数据库读写分离
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢
多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。
使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，使得服务器的负载压力不在成为整个系统的瓶颈。系统架构演化历程-反向代理和CDN加速
采用CDN和反向代理加快系统的 访问速度。
为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。系统架构演化历程-分布式文件系统和分布式数据库
随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作
数据库采用分布式数据库，文件系统采用分布式文件系统。
任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。
分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。系统架构演化历程-使用No和搜索引擎
系统引入数据库及搜索引擎。
随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。系统架构演化历程-业务拆分
系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。
为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
纵向拆分：
将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统
纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。
横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务
横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。
系统架构演化历程-分布式服务
公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。
随着业务越拆越小，应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。
Q：分布式服务应用会面临哪些问题？
(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
(2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
(3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
(4) 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？
(5) 一个服务有多个业务消费者，如何确保服务质量？
(6) 随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？
分布式应用技术基础分布式服务下的关键技术：消息队列架构消息对列通过消息对象分解系统耦合性，不同子系统处理同一个消息分布式服务下的关键技术：消息队列原理
分布式服务下的关键技术：服务框架架构
服务框架通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用
服务框架是一个点对点模型
服务框架面向同构系统
适合：移动应用、互联网应用、外部系统
分布式服务下的关键技术：服务框架原理
分布式服务下的关键技术：服务总线架构
服务总线同服务框架一样，均是通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用
服务总线是一个总线式的模型
服务总线面向同构、异构系统
适合：内部系统
分布式服务下的关键技术：服务总线原理
分布式架构下系统间交互的5种通信模式
request/response模式（同步模式）：客户端发起请求一直阻塞到服务端返回请求为止。
Callback（异步模式）：客户端发送一个RPC请求给服务器，服务端处理后再发送一个消息给消息发送端提供的callback端点，此类情况非常合适以下场景：A组件发送RPC请求给B，B处理完成后，需要通知A组件做后续处理。
Future模式：客户端发送完请求后，继续做自己的事情，返回一个包含消息结果的Future对象。客户端需要使用返回结果时，使用Future对象的.get(),如果此时没有结果返回的话，会一直阻塞到有结果返回为止。
Oneway模式：客户端调用完继续执行，不管接收端是否成功。
Reliable模式：为保证通信可靠，将借助于消息中心来实现消息的可靠送达，请求将做持久化存储，在接收方在线时做送达，并由消息中心保证异常重试。五种通信模式的实现方式-同步点对点服务模式五种通信模式的实现方式-异步点对点消息模式1
五种通信模式的实现方式-异步点对点消息模式2
五种通信模式的实现方式-异步广播消息模式
分布式架构下的服务治理
服务治理是服务框架/服务总线的核心功能。所谓服务治理，是指服务的提供方和消费方达成一致的约定，保证服务的高质量。服务治理功能可以解决将某些特定流量引入某一批机器，以及限制某些非法消费者的恶意访问，并在提供者处理量达到一定程度是，拒绝接受新的访问。
基于服务框架Dubbo的服务治理-服务管理
可以知道你的系统，对外提供了多少服务，可以对服务进行升级、降级、停用、权重调整等操作
可以知道你提供的服务，谁在使用，因业务需求，可以对该消费者实施屏蔽、停用等操作
基于服务框架Dubbo的服务治理-服务监控
可以统计服务的每秒请求数、平均响应时间、调用量、峰值时间等，作为服务集群规划、性能调优的参考指标。
基于服务框架Dubbo的服务治理-服务路由
基于服务框架Dubbo的服务治理-服务保护基于服务总线OSB的服务治理-功能介绍
基于服务总线OSB的服务治理Q：Dubbo到底是神马？
A：淘宝开源的高性能和透明化的RPC远程调用服务框架
SOA服务治理方案Q：Dubbo原理是？
注册会员, 积分 91, 距离下一级还需 109 积分
论坛徽章:2
感谢分享感谢分享感谢分享感谢分享
金牌会员, 积分 1228, 距离下一级还需 1772 积分
论坛徽章:13
good ,好好学习学习一下...
注册会员, 积分 111, 距离下一级还需 89 积分
论坛徽章:3
非常全面，非常全面，谢谢分享
新手上路, 积分 9, 距离下一级还需 41 积分
论坛徽章:0
比较清楚，看完后，大致了解分布式所需要的技术。
中级会员, 积分 330, 距离下一级还需 170 积分
论坛徽章:2
学习了、看了看整个系统进化的过程
注册会员, 积分 103, 距离下一级还需 97 积分
论坛徽章:1
图片一直加载不出来，看的不完整。966,690 三月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
分布式服务框架之服务化最佳实践
分布式服务框架之服务化最佳实践
日. 估计阅读时间:
道AI风控、Serverless架构、EB级存储引擎，尽在!
Author Contacted
相关厂商内容
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
allen chen
有借鉴意义
Re: 我的想法
Tong Jing Wen
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。1878人阅读
架构（37）
要使业务系统无极缩放，微服务架构方兴未艾。本质上，就是采用API（例如REST） 封装服务调用，形成服务框架。既然是分布式API调用，必然涉及到网络IO常见的三种方式：1）& BIO：Blocking IO，阻塞方式，一个socket用一个线程处理2）& NIO: Non-blocking IO，事件驱动，采用reactor模式，一个线程中处理多个socket，JDK1.4以上版本支持3）& AIO：Asynchronous IO，异步，采用Proactor模式，NIO在有通知时可以进行相关操作，AIO在有通知时表示相关操作已经完成，JDK1.7以上版本支持。对服务的API调用而言，分为同步服务调用和异步服务调用。&同步服务调用支持同步服务调用时，一般要有IO线程，数据队列，通信对象队列和定时任务。1）& IO线程专门负责和socket连接，进行数据的收发。2）& 收发的数据进入数据队列3）& 通信对象队列保存了多个线程使用的通信对象，主要为了阻塞请求线程，请求线程把数据放入数据队列后会生成一个通信对象，进入通信对象队列并在通信对象队列上等待。4）& 通信对象用于唤醒请求线程。5）& 如果在远程调用超时前执行完毕并返回，那么IO线程就会通知通信对象，通信对象则会结束请求线程的等待，并把结果传给请求进程，以进行后续处理6）& 定时任务负责检查通信队列中的哪些通信对象已经超时，然后这些通信对象会通知请求线程超时。异步服务调用支持异步服务调用时，常见的有四种调用方式1）& 单向请求，基本等价于一个不保证可靠到达的通知2）& 回调，是一种被动的方式。请求者设置了回调对象，把数据写入数据队列后就继续自己处理了。回调的执行在IO线程中或定时任务（主要处理超时）的线程中，建议用新的线程来执行回调。3）& Future，Java中的future非常便利，先把future放入队列，然后数据入队列，在线程中处理，等请求线程的其他处理结束后，就通过future来获取通信结果并直接控制超时。4）& 可靠异步，能保证异步请求在远程被执行。&服务端主要有两部分工作：1）& 本地服务的注册管理，服务需要注册到服务注册查找中心后才能被服务调用者发现。2）& 根据请求来定位服务并执行。启动时完成注册，监听端口，通信部分同样用NIO方式实现。IO线程进行通信的处理，一般是多个，完成协议解析。调用服务一般在工作线程进行，反序列化取决于具体实现。工作线程实际上是相互隔离的多个不同服务的线程池。&服务的升级有两种情况：1)&&&&&&接口不变，代码完善或功能完善，只是内部服务的实现有变化。2)&&&&&&需要修改原有的接口a)&&&&&&&&在接口中增加方法b)&&&&&&&&对接口的某些方法修改调用的参数列表。可以通过版本号来解决，或者在设计上考虑参数的扩展性，例如map传参服务治理是在系统采用服务框架后，完成管理服务和查看服务的功能。管理服务需要控制、操作整个分布式系统中的服务，查看则是看运行时的状态或一些具体信息、历史数据等。查看服务的具体内容包括：服务信息，服务质量，容量，依赖，分布，统计，元数据，服务查询，报表和监视。 服务管理的内容内容包括：上下线，路由，限流降级，归组，线程池管理，机房规则，服务授权。需要注意的是，在分布式系统中处理session存储问题的方式：1）& Session Sticky：负责均衡需要根据每次请求的会话标识来进行请求转发2）& Session Replication：web服务器之间增加了会话数据同步3）& Session 数据的集中存储：在web服务器数量大，session 数多时最佳4）& Cookie 使用，在客户端请求上使用session 数据
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：741017次
积分：11591
积分：11591
排名：第1079名
原创：346篇
转载：13篇
译文：35篇
评论：296条
半吊子全栈工匠一枚，20多年老码农，无所成，有初心，我相信......
文章：21篇
阅读：31726
阅读：45972
文章：17篇
阅读：65533
阅读：71899
(3)(4)(3)(3)(3)(3)(5)(5)(2)(3)(4)(11)(4)(3)(4)(3)(3)(1)(1)(1)(1)(3)(2)(14)(15)(12)(9)(3)(8)(5)(2)(3)(1)(3)(1)(1)(2)(1)(2)(1)(1)(2)(2)(1)(2)(3)(1)(1)(2)(1)(1)(3)(1)(1)(1)(14)(1)(8)(15)(23)(15)(5)(15)(14)(6)(2)(12)(13)(7)(11)(4)(3)(29)(8)(7)(4)