java分布式系统架构（分布式开发主要用到什么）

本文目录

• 分布式开发主要用到什么
• Java分布式框架有哪些
• 目前主流的Java分布式框架有哪些，学起来难不难
• 有一点java基础，如何成为一名java架构师
• java分布式架构有哪些技术
• 请问分布式架构主要有哪几种
• 如何用java 建立一个分布式系统

分布式开发主要用到什么

在谈分布式系统架构前，我们先来看看，什么是分布式系统？假设原来我们有一个系统，代码量30多万行。现在拆分成20个小系统，每个小系统1万多行代码。 原本代码之间都是直接基于Spring框架走JVM内存调用，现在拆开来，将20个小系统部署在不同的机器上，然后基于分布式服务框架（比如dubbo）搞一个rpc调用，接口与接口之间通过网络通信来进行请求和响应。所以分布式系统很重要的特点就是服务间要跨网络进行调用。此外，分布式系统可以大概可以分成两类。（一）、底层的分布式系统 比如hadoop hdfs（分布式存储系统）、spark（分布式计算系统）、storm（分布式流式计算系统）、elasticsearch（分布式搜索系统）、kafka（分布式发布订阅消息系统）等。（二）、分布式业务系统 分布式业务系统，把原来用java开发的一个大块系统，给拆分成多个子系统，多个子系统之间互相调用，形成一个大系统的整体。 举个例子，假设原来你做了一个OA系统，里面包含了权限模块、员工模块、请假模块、财务模块，一个工程，里面包含了一堆模块，模块与模块之间会互相去调用，1台机器部署。 现在如果你把他这个系统给拆开，权限系统，员工系统，请假系统，财务系统，4个系统，4个工程，分别在4台机器上部署。 然后一个请求过来，完成这个请求，员工系统去调用权限系统，调用请假系统，调用财务系统，4个系统分别完成了一部分的事情。最后4个系统都干完了以后，才认为是这个请求已经完成了。这就是所谓的分布式业务系统。

Java分布式框架有哪些

Java的几种分布式框架：1、Ehcache – Java分布式缓存框架EhCache 可以有效地减轻数据库的负载，可以让数据保存在不同服务器的内存中，在需要数据的时候可以快速存取。同时EhCache 扩展非常简单，官方提供的Cache配置方式有好几种。你可以通过声明配置、在xml中配置、在程序里配置或者调用构造方法时传入不同的参数。***隐藏网址******隐藏网址***2、ASimpleCache – 轻量级Android缓存框架ASimpleCache是一款基于Android的轻量级缓存框架，它只有一个Java文件，ASimpleCache基本可以缓存常用的Android对象，包括普通字符串、JSON对象、经过序列化的Java对象、字节数组等。***隐藏网址******隐藏网址***3、JBoss Cache – 基于事物的Java缓存框架JBoss Cache是一款基于Java的事务处理缓存系统，它的目标是构建一个以Java框架为基础的集群解决方案，可以是服务器应用，也可以是Java SE应用。***隐藏网址******隐藏网址***4、Voldemort – 基于键-值（key-value）的缓存框架Voldemort是一款基于Java开发的分布式键-值缓存系统，像JBoss Cache一样，Voldemort同样支持多台服务器之间的缓存同步，以增强系统的可靠性和读取性能。***隐藏网址******隐藏网址***

目前主流的Java分布式框架有哪些，学起来难不难

Java框架可以简化开发难度，更便于我们开发程序。所以学好Java框架还是比较重要的。Java的框架主要有：SpringMVC、Spring、Mybatis、Dubbo、Maven、RabbitMQ、Log4j、Ehcache、Redis、Shiro。不过这十个我们不需要都学会，只要学会其中四五个比较常用的就可以。

1.SpringMVC。Spring MVC是一种基于Java的实现了Web MVC设计模式的请求驱动类型的轻量级Web框架，主要是帮助我们简化日常的Web开发;

2.Mybatis。MyBatis 是支持普通 SQL查询，存储过程和高级映射的优秀持久层框架;

3.Spring。Spring深得企业的青睐;

4.Maven。越来越多的开发人员开始使用maven。

扩展资料：

java的学习，可以按照优就业的java课程大纲进行学习：

一、JavaEE基础

Java基础语法、面向对象、核心类库、集合、异常、IO、线程、JDK新特性

二、JavaWeb开发

前端技术、数据库、JAVA数据库操作、软件服务器及服务器相关技术、动态网页JSP、AJAX、优就业-在线医疗系统

三、Java高级框架

SpringMVC、MyBatis、Spring、MySQL高级、Linux&Redis&Nginx、Maven、中公MIS权限系统

四、大型微服务分布式项目实战

SpringBoot、SpringCloud、Git、Dubbo、Zookeeper、AngularJS、Spring Security、BCrypt加密、FastDFS、分布式事务处理、Redis Cluster、Solr、SolrCloud、Freemarker、JMS、短信发送平台、SSO解决方案、CORS、Twitter的Snowflake、SpringTask、Maven Profile、MongoDB简介、MyCat、Docker、Jenkins、东易买大型电商实战、东易众筹

五、微服务大型项目实战。

有一点java基础，如何成为一名java架构师

在Java程序员行业中，有不少Java开发人员的理想是成为一名优秀的Java架构师，Java架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个Java架构师工作的好坏决定了整个软件开发项目的成败。那么Java架构师需要掌握哪些知识点呢？

1、框架源码分析

设计模式：Singleton单例模式，Factory工厂模式，Proxy代理模式，Template模板模式，Prototype原型模式等

Spring5：Spring提醒结构，IOC注入原理，AOP设计原理，Spring事务处理机制，SpringMVC，Spring源码分析。

Mybatis：Mybatis体系结构，Mybatis核心应用与配置，Mybatis关联查询，与Spring集成，Mybatis源码分析。

2、性能优化

JVM性能优化：剖析JVM整体结构，详解垃圾回收机制GC,JVM性能调优与工具排查

Nginx调优：Nginx项目架构，Nginx核心配置，Nginx负载算法配置

Tomcat调优：Tomcat运行机制及框架，Tomcat线程模型，Tomcat性能调优

MySQL性能优化：SQL执行计划，AQL优化，索引优化。

3、掌握池技术

对象池，连接池，线程池，Java反射技术，写框架必备的技术，但是有严重的性能问题，替代方案Java字节码技术。

4、掌握nio，值得注意的是“直接内存”的特点，使用场景。

5、掌握Java多线程同步异步。

6、掌握Java各种集合对象的实现原理，了解这些可以让你在解决问题时选择合适的数据结构，高效的解决问题。

7、熟练使用各种数据结构和算法，数组、哈希、链表、排序树就是一句话要么是时间换空间要么是空间换时间。

8、熟悉tcp协议，创建连接三次握手和断开连接四次握手的整个过程，不了解的话，无法对高并发网络应用做优化。

***隐藏网址***

10、熟悉系统集群、负载均衡、反向代理、动静分离，网站静态化。

11、掌握分布式。

Java并发编程和网络编程：Java线程状态，线程池，线程通信，线程安全，Netty高性能原理

分布式开发框架：分布式系统口调用技术：RPC，Apache分布式系统Zookeeper原理与应用，阿里Dubbo设计思想与应用

分布式中间件：分布式服务器治理，分布式消息通信，分布式数据缓存，MongoDB企业集群解决方案

12、掌握数据库的设计能力，对它基本的参数优化，慢查询日志分析，主从复制的配置，至少要成为半个mysqldba。

java分布式架构有哪些技术

　　既然是分布式系统，系统间通信的技术就不可避免的要掌握。

　　首先，我们必须掌握一些基本知识，例如网络通信协议（例如TCP / UDP等），网络IO（Blocking-IO，NonBlocking-IO，Asyn-IO），网卡（多队列等）。   了解有关连接重用，序列化/反序列化，RPC，负载平衡等的信息。

　　在学习了这些基本知识之后，您基本上可以在分布式系统中编写一个简单的通信模块，但这实际上还远远不够。 现在，您已经进入了分布式字段，您已经对规模有很多要求。 这意味着需要一种通信程序，该程序可以支持大量连接，高并发性和低资源消耗。

　　大量的连接通常会有两种方式：

　　大量client连一个server

　　当前在NonBlocking-IO非常成熟的情况下，支持大量客户端的服务器并不难编写，但是在大规模且通常是长连接的情况下，有一点需要特别注意 ，即服务器挂起时不可能所有客户端都在某个时间点启动重新连接。 那基本上是一场灾难。 我见过一些没有经验的类似案例。 客户端规模扩大后，服务器基本上会在重新启动后立即刷新。 大量传入连接中断（当然，服务器的积压队列首先应设置为稍大一些）。 可以使用的通常方法是在客户端重新连接之前睡眠一段随机的时间。 另外，重连间隔采用避让算法。

　　一个client连大量的server

　　有些场景也会出现需要连大量server的现象，在这种情况下，同样要注意的也是不要并发同时去建所有的连接，而是在能力范围内分批去建。

　　除了建连接外，另外还要注意的地方是并发发送请求也同样，一定要做好限流，否则很容易会因为一些点慢导致内存爆掉。

　　这些问题在技术风险上得考虑进去，并在设计和代码实现上体现，否则一旦随着规模上去了，问题一时半会还真不太好解。

　　高并发这个点需要掌握CAS、常见的lock-free算法、读写锁、线程相关知识（例如线程交互、线程池）等，通信层面的高并发在NonBlocking-IO的情况下，最重要的是要注意在整体设计和代码实现上尽量减少对io线程池的时间占用。

　　低资源消耗这点的话NonBlocking-IO本身基本已经做到。

　　伸缩性

　　分布式系统基本上意味着规模不小。 对于此类系统，在设计时必须考虑可伸缩性。 在体系结构图上绘制的任何点，如果请求量或数据量继续增加，该怎么办？ 通过添加机器来解决。 当然，此过程不需要考虑无限的情况。 如果您有经验的建筑师，从相对较小的规模到非常大型的范围，那么优势显然并不小，而且它们也将越来越稀缺。  。

　　横向可扩展性（Scale Out）是指通过增加服务器数量来提高群集的整体性能。 垂直可伸缩性（Scale Up）是指提高每台服务器的性能以提高集群的整体性能。 纵向可扩展性的上限非常明显，而分布式系统则强调水平可伸缩性。

　　分布式系统应用服务最好做成无状态的

　　应用服务的状态是指运行时程序因为处理服务请求而存在内存的数据。分布式应用服务最好是设计成无状态。因为如果应用程序是有状态的，那么一旦服务器宕机就会使得应用服务程序受影响而挂掉，那存在内存的数据也就丢失了，这显然不是高可靠的服务。把应用服务设计成无状态的，让程序把需要保存的数据都保存在专门的存储上(eg. 数据库)，这样应用服务程序可以任意重启而不丢失数据，方便分布式系统在服务器宕机后恢复应用服务。

　　伸缩性的问题围绕着以下两种场景在解决：

　　无状态场景

　　对于无状态场景，要实现随量增长而加机器支撑会比较简单，这种情况下只用解决节点发现的问题，通常只要基于负载均衡就可以搞定，硬件或软件方式都有；

　　无状态场景通常会把很多状态放在db，当量到一定阶段后会需要引入服务化，去缓解对db连接数太多的情况。

　　有状态场景

　　所谓状态其实就是数据，通常采用Sharding来实现伸缩性，Sharding有多种的实现方式，常见的有这么一些：

　　2.1 规则Sharding

　　基于一定规则把状态数据进行Sharding，例如分库分表很多时候采用的就是这样的，这种方式支持了伸缩性，但通常也带来了很复杂的管理、状态数据搬迁，甚至业务功能很难实现的问题，例如全局join，跨表事务等。

　　2.2 一致性Hash

　　一致性Hash方案会使得加机器代价更低一些，另外就是压力可以更为均衡，例如分布式cache经常采用，和规则Sharding带来的问题基本一样。

　　2.3 Auto Sharding

　　Auto Sharding的好处是基本上不用管数据搬迁，而且随着量上涨加机器就OK，但通常Auto Sharding的情况下对如何使用会有比较高的要求，而这个通常也就会造成一些限制，这种方案例如HBase。

　　2.4 Copy

　　Copy这种常见于读远多于写的情况，实现起来又会有最终一致的方案和全局一致的方案，最终一致的多数可通过消息机制等，全局一致的例如zookeeper/etcd之类的，既要全局一致又要做到很高的写支撑能力就很难实现了。

　　即使发展到今天，Sharding方式下的伸缩性问题仍然是很大的挑战，非常不好做。

　　上面所写的基本都还只是解决的方向，到细节点基本就很容易判断是一个解决过多大规模场景问题的架构师，:)

　　稳定性

　　作为分布式系统，必须要考虑清楚整个系统中任何一个点挂掉应该怎么处理（到了一定机器规模，每天挂掉一些机器很正常），同样主要还是分成了无状态和有状态：

　　无状态场景

　　对于无状态场景，通常好办，只用节点发现的机制上具备心跳等检测机制就OK，经验上来说无非就是纯粹靠4层的检测对业务不太够，通常得做成7层的，当然，做成7层的就得处理好规模大了后的问题。

　　有状态场景

　　对于有状态场景，就比较麻烦了，对数据一致性要求不高的还OK，主备类型的方案基本也可以用，当然，主备方案要做的很好也非常不容易，有各种各样的方案，对于主备方案又觉得不太爽的情况下，例如HBase这样的，就意味着挂掉一台，另外一台接管的话是需要一定时间的，这个对可用性还是有一定影响的；

　　全局一致类型的场景中，如果一台挂了，就通常意味着得有选举机制来决定其他机器哪台成为主，常见的例如基于paxos的实现。

　　可维护性

　　维护性是很容易被遗漏的部分，但对分布式系统来说其实是很重要的部分，例如整个系统环境应该怎么搭建，部署，配套的维护工具、监控点、报警点、问题定位、问题处理策略等等。

请问分布式架构主要有哪几种

分布式架构CORBA (Common Object Request Broker Architecture) 是在1992年由OMG(Open Management Group) 组织提出的。那时的分布式应用环境都采用Client/Server架构，CORBA的应用很大程度的提高了分布式应用软件的开发效率。 当时的另一种分布式系统开发工具是Microsoft的DCOM(Distributed Common Object Model)。Microsoft为了使在Windows平台上开发的各种应用软件产品的功能能够在运行时(Runtime)相互调用(比如在Microsoft Word中直接Excel文件)，实现了OLE(Linked and Embedded Object)技术，后来这个技术衍生为COM(Common Object Model)。 瑭锦-TANJURD表示随着Internet的普及和网络服务(Web Services)的广泛应用, Browser/Server架构的模式逐渐体现出它的优势。于是，Sun公司在其Java技术的基础上推出了应用于B/S架构的J2EE的开发和应用平台;Microsoft也在其DCOM技术的基础上推出了主要面向B/S应用的.NET开发和应用平台。

如何用java 建立一个分布式系统

分布式架构的演进系统架构演化历程-初始阶段架构初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP特征：应用程序、数据库、文件等所有的资源都在一台服务器上。描述：通常服务器操作系统使用Linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用MySQL，汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。系统架构演化历程-应用服务和数据服务分离好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver特征：应用程序、数据库、文件分别部署在独立的资源上。描述：数据量增加，单台服务器性能及存储空间不足，需要将应用和数据分离，并发处理能力和数据存储空间得到了很大改善。系统架构演化历程-使用缓存改善性能特征：数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力。描述：系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。缓存分为本地缓存和远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。系统架构演化历程-使用应用服务器集群在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来 是请求数太高导致需要排队等待，响应速度变慢特征：多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。描述：使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。系统架构演化历程-数据库读写分离享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢特征：多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。描述：使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，使得服务器的负载压力不在成为整个系统的瓶颈。系统架构演化历程-反向代理和CDN加速特征：采用CDN和反向代理加快系统的 访问速度。描述：为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。系统架构演化历程-分布式文件系统和分布式数据库随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作特征：数据库采用分布式数据库，文件系统采用分布式文件系统。描述：任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。系统架构演化历程-使用NoSQL和搜索引擎特征：系统引入NoSQL数据库及搜索引擎。描述：随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。系统架构演化历程-业务拆分特征：系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。描述：为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。系统架构演化历程-分布式服务特征：公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。描述：随着业务越拆越小，应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。Q：分布式服务应用会面临哪些问题？A：(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。(2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。(3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？(4) 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？ (5) 一个服务有多个业务消费者，如何确保服务质量？(6) 随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？ Java分布式应用技术基础分布式服务下的关键技术：消息队列架构消息对列通过消息对象分解系统耦合性，不同子系统处理同一个消息分布式服务下的关键技术：消息队列原理分布式服务下的关键技术：服务框架架构服务框架通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用服务框架是一个点对点模型服务框架面向同构系统适合：移动应用、互联网应用、外部系统分布式服务下的关键技术：服务框架原理分布式服务下的关键技术：服务总线架构服务总线同服务框架一样，均是通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用服务总线是一个总线式的模型服务总线面向同构、异构系统适合：内部系统分布式服务下的关键技术：服务总线原理分布式架构下系统间交互的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原理是？A：-结束-