您的位置 首页 java

JAVA分布式系统的演变过程,主流的分布式框架,看看这篇一定够了

(一)分布式发展的历史和背景

  • 场景

一家做政府系统OA系统的公司老板,发现跟竞争对手比发现自己的系统的架构不是分布示的,招标的时候不是特别的顺利,就找到技术负责人问,把系统架构升级成分布示架构要多长时间啊?技术负责人网上查了查 dubbo 官网,看了看 Demo 这不很简单吗,拍着胸脯一个月能升级好。

  • 这位技术经理在改造过程中可能会遇到什么风险和问题?

有些老铁有工作经验的在传统行业做过的印象比较深刻,OA,ERP,政务系统。大家一起想想,这个技术经理把单体架构改造成 分布式系统 说要一个月的时间升级好。

1.新功能

业务的问题,业务还是在持续的增长,新开发的业务是放到新系统上还是放在旧系统里面去,放在旧系统里面实现的周期是可以估算出来的,放在新系统可能还不稳定开发周期不容易预估,功能如果对于业务部门很重要的话,业务愿意在新系统开发吗?

2.旧bug

旧系统的bug是不是需要改2遍,新旧都要改一遍,尤其是比较大的功能,这个非常的明显。

3.业务完整性

比较大的系统都是由多个人一起开发的,A开发一半跑路了,B应聘来了继续开发,B又了新项目,让C接手,尤其是传统的功能都没有产品经理,程序员自己想自己开发。就算有产品经理也来来回回换了好几遍了。前人挖坑后人填,怎么填,拿身体去填。完整的业务都没人能说清楚,如何改造成分布式系统?就算是不改造成分布式系统,重构也会遇见这种问题。我相信有看我文章的老铁【正在经历】。看老板的思路了,一般的老铁都是选择长痛,继续玩下去选择不改造,最后忍无可忍,自己把自己从这个公司炒了。

4.团队协作方式转变

原来开发都是采用SSM这种框架,但是采用了分布式之后,还需要用到zookeeper,redis,dubbo, springcloud ,这种新技术,这些开发人员如何使用这些技术还来得及吗?

5.系统交付方式的转变

在传统开发方式,产品的迭代都是由业务经理来确定的,业务经理从客户那里获取到需求后,开发完成进行系统的迭代,如果是分布式的系统,这个时候变的很复杂,不可能按照业务经理推动上线。本身应该有产品迭代的周期。

6.总结

单体应用升级成分布式应用,绝对不仅仅是由技术上可以解决的,不是技术OK就OK了,你会dubbo了,你会springclud了就可以保证迁移成分布式的,这一点一定要明白要认可。这些问题解决涉及业务部门及整个技术部门(开发、测试、 运维 )协商与工作标准的制定。而且在升级过程中也不是一次性升级的,如果一次性升级的只会【SI】的惨。业务相关问题暂不做讨论,如何和业务部门进行友好的协商,如何将单体应用迁移成为分布式,每个公司不同的业务,不同的环境,这里就不讨论了。技术架构上应该要清楚自己的职责是,如何通过技术手段把业务波动降至最低、开发成本最低、实施风险最低。要解决这些问题的前提之一就是要对 分布式架构 有整体的认知,不是你会个分布式框架,会个RPC框架就搞的定的。相信举上边的例子大家应该是深有感触的。

提高分布式叫的整体认知

  • 1.系统架构的发展历史

学习一门技术一定要懂它的历史,忘记历史就意味着背叛,一定要了解它的历史,知道它是如何一步步走过来的。

  • 2.一套分布式系统的组成

了解分布式架构的本质和理论搞清楚,不管是用dubbo或者springclud,它们底层功能点都是一样的,根据根据某个功能有强和弱之分,本质上他们是没有区别的。

  • 3.分布式架构所带来的成本与风险

其实技术只是其中的一块,更多的是提前预支对开发模式的转变,提前怼风险有个预判。遇到这些问题不至于手忙脚乱。不至于很茫然。

(二)架构的发展历史

  • 单体式架构

应用程序,静态文件,数据库全部都在一台机器上。那个年代写个网站10万块,那个年代程序员不会说自己去搬砖,程序员还是一份体面的工作,那个时候 马云 还是推销他的 阿里巴巴 马化腾 还是写他的qq,那个时候的房价郑州估计才300多一平,股市只有1700多点。到现在一切都变了。

在单体架构里面,客户端可能是cs的,也可能是bs的,服务里面包括所有的模型。所有的请求都包括在server里面,数据库只有一个。实现这个架构更多的是sql语句写好,业务更多的是通过sql来实现的。那个时候hibernate还没有,也没有ORM框架,用这jdbc写的挺爽,当model越来越多的时候,开发效率变的很低,这个项目可能几百个模块,光构建就要花半个小时,我记得公司原来有个项目,那时候才大学毕业那个项目名字叫98系统,就是98年开发完毕的,构建需要半个小时,那时候电脑内存才2g,用的是奔4cpu。其中一个模块报错,需要重新构建一次,都是全部写完看了几遍才敢测试,因为构建太慢了。

  • 垂直架构

大家后来都想开了,都在一个项目开发太费劲了,不如分成很多的小项目吧,各自维护各自的数据库。每个团队维护自己的,性能和效率都解决了。

这种的问题server1和server2有相同的功能的话,它们之间是不会有任何的交互的,完全是进行隔离的。当初09年开始做开发的时候,为了让2个系统结合起来就用了cas做统一登录,用户在B系统中想看A系统的信息,需要登录A系统的模块,输入查询的内容进行查看,用户并不知道是2个系统,其实我们很清楚。他在两个系统之间进行跳转。数据基本不共享。更多的是关心界面,基本界面开发完了,系统也就开发完了。60%–80%是开发界面。没有接口的概念。完完全全是隔离开来的。如果想交互成本很高。当时有同事用kettle的etl进行数据抽取,抽取后定时的放到B系统中。

  • 分布示架构

将公共的部分抽取成一个服务。公共部分是在通过公共服务来提供。之前垂直的架构,复杂的业务,不熟悉另一个系统的业务的话,根本数据库是看不懂的。

公共部分的抽离,如果性能受不了,可以部署在不同的机器上,它们各自的数据库。 也就分了:UI层,业务层,底层服务层,存储层。这也就是分布式框架常用的层次逻辑。提高弹性扩展能力。

抽取公共服务,保证程序的弹性扩张,也就是程序量增加的时候访问量也随之增加。分布式架构的初衷。分布式架构不会提高开发上的效率。更多是加大了开发的复杂度。让生产效率变慢。有些老板不懂盲目的追求技术,记得原来做桌面开发,其实c#更合适,但是有的老板觉得 java 特别特别的热去搞java开发,后来发现用java这些桌面程序人难找,人又贵,肠子都悔青了。合适性。07年才工作的时候,公司用delphi更佳,是不是暴露年龄了哈哈。

  • 智能架构

节点特别多,内网开销非常的大,如果采用智能编排,采用部署在同一台机器上,通过监控工具,智能的在同一台机器,是不是内网的IO就得到了很好的解决,并发很大的时候性能的瓶颈就是在内网IO上面,1000MB的带宽都带不动。如果server1有10个节点访问很频繁,server2也是10个节点都没多少人访问,如果有了只能架构,也就是容器编排就可以很好的进行编排,让server1随时的加大,server2随时的减少。这个是随时通过按钮就可以进行编排的了,跟nginx负载不是一个概念。智能的追踪服务调用链之间的关系,如果是base server1修改后,智能的分析出来那些用例收到了影响。好进行回归测试。这也是未来的架构,智能的服务编排。开始学docker吧。未来属于它。

  • 回顾

那时候机器都是上百万的,用的数据库都是oracle的,关联查询随便写,但是现在用了分布式mysql,不敢写,随时可能让数据库崩。一个技术非常先进,但是不能落地的系统只有一个作用,就是写ppt。写完ppt用来吹NB。

(三)如何着手架构一套分布式系统

拒绝吹NB。实现分布式框架最核心的功能是什么?

我来回答:【调用】

  • RPC远程调用技术:

拿几个大家比较熟悉的来举例:RMI 、Web

Service、Http

  • 如果服务端不是单个的话,实际是服务端是多个,要解决的问题又来了?

1. 负载均衡

到底是随机调还是轮询调,这个就是负载均衡

2.容错

如果调用其中一台调用出错了怎么办?继续调?还是换个节点?还是等一会在调?

3.服务配置

服务端地址配置在哪里?client需要知道node1和node2的IP,直接在client直接写ip,如果增加node3,或者把node1去掉,是不是要频繁的修改,服务频繁的重启,麻烦啊!可以搞个注册中心。节点起来了部署到注册中心中。节点发生变化通知client。

3.健康检测

服务关了宕机了,恢复后怎么办?

PS:另外分享一个心得:很多公司需要一套框架,业内有比较成熟的开源系统,但是技术经理还是要选择自主去开发一套,这是为什么呢?为了kpi,大公司kpi要求比较高,为了突显业绩。也是一种自我保护。做开发不能老开发,也要学会自我的保护。程序员也是要追逐利益的。说服一个人不要光讲道理,有句话是利益对了道理自然对了。自我成长的时候,学习只选择最对的。

轻量级架构 会采用 Http+Nginx

负载均衡+容错+服务配置+健康检测 这些功能怎么解决呢?一个一个的去编码实现么?。有没有现成的方案可以直接实现这些功能?Nginx完全支持这些功能。所以企业在做轻量级架构 会采用 Http+Nginx 方式。

这个架构有什么瓶颈,nginx挂了的话,是不是服务都不行了,可以在中间层可以搞keeplived,做nginx的负载。

完成nginx内部的负载,Nginx本身还可以根据业务进行垂直拆分。如果用户server1,直接到serverN了怎么办,其实这个架构本身就是轻量级的,本身就支持不了了。

有老铁爱说,性能不够加服务器,在于自身是否支持弹性的扩展,如果系统不支持,加服务器没用的。

  • 优点

简单快速、几乎没有学习成本

  • 适用场景

轻量级分布式系统、局部分布式架构。

  • 瓶颈

Nginx中心负载、Http传输、JSON 序列化 、开发效率、运维效率。

1.Http传输

http传输本身比较复杂有请求头,有请求体,传输内容比较多。如果RPC就不用考虑这些。

2.JSON序列化

真心不高,比java的二进制序列化效率还要低,最大的瓶颈就在于json的解析上。

3.运维效率

server1,server2的配置都是在nginx上的,配置多的话对于运维人员增加了工作量。

4.开发效率

也不是不高,反正就是需要解析麻烦,还得拼麻烦。

5.Nginx中心负载

层和层之间通信,消耗nginx,nginx中心进行负载,肯定没有直接连接块,毕竟有中间商【赚差价】

  • 基于瓶颈考虑大型系统需要一个更加专业的方案,该方案必须做到以下几点:

springcloud和dubbo就是按照这些设计方案来进行设计的。

1.去中心化,客户端直连服务端

2.动态注册和发现服务

3.软负载均衡实现

4.高效稳定的网络传输

5.高效可容错的序列化

  • (1)注册中心逻辑
  • 1.服务端动态注册服务提供者信息
  • 2.客户端从注册中心接收服务提供者信息,并存储至本地缓存
  • 3.注册中心实时监听提供者状态,如果变更将即时通知客户端
  • (2)调用逻辑
  • 1.负载均衡
  • 2.容错
  • 3.对服务调用者透明,操作数据库的时候只需要操作对应的接口,就可以完成对数据库的操作,这个就是透明。
  • (3)传输模块
  • mina、 servlet 容器、 netty
  • (4)序列化模块
  • kryo、hessian、java、protobuf、JSON、XML
  • 所有RPC框架的逻辑

主流的框架比较

  • spring cloud

本身是个技术栈,

服务发现——Netflix Eureka

客服端负载均衡——Netflix Ribbon

断路器——Netflix Hystrix

服务网关——Netflix Zuul

分布式配置——Spring Cloud Config

  • Doubbo

Provider:暴露服务的服务提供方

Container:服务运行容器

Consumer:调用服务的消费方

Registry:注册服务与发现服务中心

Monitor:统计服务调用的监控中心(可有可无)

官网:

PS:微服务的业内主流的java框架就是springcloud 和dubbo,他们的设计思路都是按照分布式的设计思路来的,主要还是围绕服务,发现,注册,调用,负载。一定要明白他的设计思路。这样对学习springcloud和dubbo好处多多。

文章来源:智云一二三科技

文章标题:JAVA分布式系统的演变过程,主流的分布式框架,看看这篇一定够了

文章地址:https://www.zhihuclub.com/190801.shtml

关于作者: 智云科技

热门文章

发表回复

您的电子邮箱地址不会被公开。

网站地图