「java必备架构」java架构设计

本篇文章给大家谈谈java必备架构，以及java架构设计对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、全面了解Java媒体架构JMF
• 2、java微服务架构有哪些
• 3、Java的技术架构有哪些
• 4、java架构有哪些

全面了解Java媒体架构JMF

Java媒体架构(JMF)是一个令人激动的通用的API 它允许Java开发者用许多不同的方法处理媒体 本指南主要通过使用工作的例子提供一个JMF的一些主要的特征的概述 阅读完本指南后 你将会明白JMF体系结构中的主要播放功能 你同样能正确的使用JMF 使用现存的例子和可为更多特殊功能扩展的源代码

本指南包含着以下主题

· 下载和安装JMF

· 主要的JMF类以及它们在JMF体系结构中的应用

· 播放本地的媒体文件

· 为媒体的存取和操作制作以和图形用户界面(GUI)

· 通过网络传播媒体

· 通过网络接收媒体

几乎所有的媒体类型的操作和处理都可以通过JMF来实现 全面的讨论JMF所提供的所有特征已经超过了本指南的范围 我们将使用三个简单的媒体应用程序来学习此框架的构建模块 通过这个方法 本指南将为你未来学习和实施更多特殊的应用提供准备

我应该使用此指南吗?

本指南会带你学习使用JMF工作的基础 为完成这些 我们会创建三个的独立工作的例程序 每个例子都会建立前一个例子的基础上 显示JMF功能性的不同方面

在本指南中的例子假定你曾经使用过并且已经熟悉了Java程序语言 除了Java核心和JMF的类之外 我们会使用一些Java AWT和Swing类(用于创建GUI) 也会有一些Java网络类(用于在网络中传输媒体) 对GUI和网络类一些熟悉有助于你更快的明白观点和这里的例子 但并非是阅读本指南必须的

我们将学习的例程序如下

· 一个简单的音频播放器(JMF的HelloWorld应用) 这个字符界面的播放器通过在命令行中简单的输入媒体文件的名字就可以播放大多数的音频类型 此音频播放器的演示大体上显示了JMF的特有的类

· 一个图形界面的媒体播放器 我们将使用JMF内置的接口组件来建立图形界面 所以在此练习中必须有一些图形界面的编程经验 这个媒体阅览器演示使用了一些Java AWT和Swing类来为用户显示图形组件

· 一个媒体广播应用 此应用程序允许一个本地媒体文件通过网络传播 此程序能灵活的使媒体只传输到指定的网络节点 或者传输到一个子网络中的所有节点 此演示使用了一些Java的网络APIs来在网络中传输媒体

作为第三个练习的一部分 我们将修改图形界面的播放器 让其能接收并且播放媒体

跳至 页观看Resources 文章 指南 和其他参考书目的列表 这会帮助你学习到更到关于此指南包括的主题

安装需求

要运行此指南中的例程序 你需要如下的工具和组件

·　Java 平台 标准版 编译和运行演示程序

·　Java媒体框架 版本 a或者更高

· 一块已经安装并且配置号的适当的声卡

· 一台或者多台测试机器

· 演示的源代码文件在mediaplayer jar中

最后的一个演示应用显示了JMF在网络中的应用 如果需要 此演示能运行在一个独立的机器上 使用此机器即是传输方也是接收方 可是要观察到在网络中使用JMF的所有功能 你仍然需要至少两台联网的机器

在 页中的Resources可下载Java 平台 完整的源代码文件 以及其他一些完成本指南所需要的工具

下载安装文件

将JMF安装到你的计算机中的第一步是在JMF的主页中下载安装文件 它同样包括了JMF源代码和API文档的链接 页的Resources中有下载JMF的链接

目前 JMF有Windows Solaris Linux等版本 以及可运行在任何装有虚拟机的计算机上一个纯Java版本 为了增加性能 你需要下载一个与你操作系统所适应的版本 任何在一个操作系统JMF版本下书写和编译的代码都可以方便的移植到另外的操作系统上 例如 如果你下载了一个Solaris版本的JMF并且编译了一个类 这些类就可以在Linux上使用 不会有任何问题

作为选择 你可以选择下载纯Java版本 或者跨平台版本的JMF 这些版本没有使用操作系统特有的库文件 如果没有合适的JMF版本适合的操作系统 那么跨平台版本就是一个不错的选择

安装JMF

下载完JMF安装程序后 双击安装程序的图标

大部分安装程序都会有个选项 安装本地库到系统目录中;例如 Windows版本安装程序会有一个选项 Move DLLs to Windows/System directory 最好将此选项选中 因为它能确保这些操作系统的库文件能正确的安装

在安装的过程中 你还需要选择项目来更新系统的CLASSPATH和PATH变量 如果这些选项被关闭 那么在你编译和运行本指南的例程序的时候就需要在classpath中引入JMF的jar文件

第二节 一个简单的音频播放器

浏览

在本节中 我们将进行创建一个简单的音频播放器的第一个练习 本例将介绍Manager类和Player接口 中两个都是建立大多数基于JMF应用的重要部分

本例的功能目标是在字符界面下播放本地的音频文件 我们将学习此源代码 并了解每一行所做的任务 完成本节后 你将会有一个基于JMF的可播放包括MP WAV AU等多种音频文件的演示程序

在本练习后的源代码分类种可查询文件SimpleAudioPlayer java

引入必要的类

SimpleAudioPlayer类中包括了一些调用 在其前几行中需要引入所有必要的类

import dia *;import java io File;import java io IOException;import URL;import MalformedURLException;

The dia包是由JMF定义的多个包之一 dia是一个核心包 包括了定义Manager类和Player接口等 本节中 我们主要学习Manager类和Player接口 其余的dia类放在后面的章节中

除了引入dia声明外 以上的代码片断引入了一些创建媒体播放器的输入的声明

Player接口

在下面的代码片断中 创建一个公共类SimpleAudioPlayer并举例定义一个Player变量

public class SimpleAudioPlayer {private Player audioPlayer = null;

术语Player听起来由点熟悉 因为它是建立在我们公用的音频或者视频播放器的基础上的 事实上 这个接口的例子就像是当作它们的真实的副本 Players揭示了一个实体上的媒体播放器(如立体音箱系统或者VCR)涉及到功能上的方法 例如 一个JMF媒体播放器可以开始和结束一个媒体流 在本节种 我们将使用Player的开始和结束功能

在一个文件上创建一个Player

使用JMF获得一个特定媒体文件的Player实例非常简单 Manager类在JMF中如同一个工厂制作许多的特殊接口类型 包括Player接口 因此 Manager类的责任就是创建Player实例 如下例

public SimpleAudioPlayer(URL url) throws IOException NoPlayerException CannotRealizeException{audioPlayer = Manager createRealizedPlayer(url);}public SimpleAudioPlayer(File file) throws IOException NoPlayerException CannotRealizeException{this(file toURL());

如果你看完本节的代码 你可以注意到Manager类包含了创建一个Player实例的其他方法 我们会研究其中的一些 如在后面的章节中的DataSource或者MediaLocator的实例化

Player的状态

JMF定义了大量的一个Player实例可能存在的不同状态 如下

· Prefetched

· Prefetching

· Realized

· Realizing

· Started

· Unrealized

使用这些状态

因为使用媒体常常是资源非常密集的 由JMF对象揭示的许多方法都是不闭塞的 允许一系列事件监听的状态改变的异步通知 例如 一个Player在它可以启动之前 必须经过Prefetched和Realized状态 由于这些状态的改变都需要一些时间来完成 JMF媒体应用可以分配一个线程来初始化创建Player实例 然后再继续其他的操作 当Player准备就绪的时候 它会通知应用程序其状态已经改变

在一个如同我们的这样简单的程序中 多功能性的类型并不是很重要 处于这个原因 Manager类也提供了一些创建Realized player的有用方法 调用一个createRealizedPlayer()方法来阻塞调用线程 直到player达到Realized状态 为了调用一个无阻塞的创建player的方法 我们在Manager类中使用了一个createPlayer()方法 下面的一行代码中创建了一个我们需要在例程序中使用的

Realized player audioPlayer = Manager createRealizedPlayer(url);

启动和停止Player

设定一个Player实例的启动或是停止就如同调用Player的一个简单的认证方法 如下所示

public void play() {audioPlayer start();}public void stop() {audioPlayer stop();audioPlayer close();}

调用SimpleAudioPlayer类中的play()方法来实现调用Player实例的start()方法 调用此方法后 你能听到本地的喇叭的声音文件 同样的 stop()方法使player停止并且关闭掉Player对象

对于读取和或者播放本地媒体文件来说 关闭Player实例释放所有资源是一个有用的方法 因为这是一个简单的例子 关闭Player是终止一个会话可接受的方法 但是在实际的应用中 你需要小心的确认在除掉Player之前必须要关闭掉 一但你已经关闭掉player 在再次播放一个媒体之前你必须要创建一个新的Player实例

lishixinzhi/Article/program/Java/hx/201311/26628

java微服务架构有哪些

微服务有助于开发人员用更低的成本和更少的错误来开发程序。

常用的微服务框架：

1、Spring Boot

Spring Boot是Spring的一个特定版本，它通过对配置细节的处理，使微服务构建更加简便。创建Spring Boot旨在自启动任何类型的Spring项目，而不仅仅是微服务。应用程序完成后，Spring Boot将在Web服务器中混合，并输出一个JAR文件，JVM除外。你可以将其视为原始Docker容器，这也是许多负责构建微服务的开发者都非常喜欢Spring Boot的原因。

2、Dropwizard

Dropwizard框架为开发者提供了一个非常简单的模型，里面包含了许多重要的模块，你可以根据需求添加一些业务逻辑，或者配置其他内容，最后你会发现JAR文件非常小，并且能够快速启动。

Dropwizard最大的限制可能是缺乏依赖注入。如果你希望使用依赖项注入来保持代码的整洁和松散耦合，则需要自己添加库，这点和Spring不同，但是现在Dropwizard也支持大多数功能，包括日志记录、健康检查和提供弹性代码。

3、Cricket

是一个用于快速API开发框架。Cricket很小，尽管它包括许多额外的功能，如键值数据存储，以避免连接数据库和调度程序来控制后台重复处理。没有添加复杂性或其他依赖项，因此很容易将代码添加到Cricket并启动独立的微服务。

4、Jersey

开发web服务的标准方法之一是RESTful web服务的Java API(又名JAX-RS)，这是Jersey框架中实现的通用规范。这种方法主要依赖于使用注释来指定路径映射和返回细节。从参数解析到JSON打包的所有其他内容都由Jersey处理。

Jersey的主要优点是它实现了JAX-RS标准，这个特性非常受欢迎，一些开发人员习惯将Jersey与Spring Boot结合在一起使用。

5、Play

体验JVM跨语言能力的最佳方式之一是使用Play框架，这是可以与Java或任何其他JVM语言兼容的。它的基础非常现代，具有异步、无状态的模型，不会让试图跟踪用户及其会话数据的线程使服务器过载。还有许多额外的特性可以用来充实网站，比如OpenID、验证和文件上传支持。Play代码库已经发展了十多年，因此你还会发现类似于对XML的支持的这种古老的功能。play既成熟又轻盈，这种组合还是比较有特色的。

当然，常用的Java微服务框架还有Swagger、Helidon、WildFly Thorntail等，在此就不多赘述了。

希望能帮到你，望采纳！！！

Java的技术架构有哪些

服务分离

随着系统的的上线，用户量也会逐步上升，很明显一台服务器已经满足不了系统的负载，这时候，我们就要在服务器还没有超载的时候，提前做好准备。

由于我们是单体架构，优化架构在短时间内是不现实的，增加机器是一个不错的选择。这时候，我们可能要把应用和数据库服务单独部署，如果有条件也可以把文件服务器单独部署。

反向代理

为了提升服务处理能力，我们在Tomcat容器前加一个代理服务器，我一般使用Nginx，当然你如果更熟悉apache也未尝不可。

用户的请求发送给反向代理，然后反向代理把请求转发到后端的服务器。

严格意义上来说，Nginx是属于web服务器，一般处理静态html、css、js请求，而Tomcat属于web容器，专门处理JSP请求，当然Tomcat也是支持html的，只是效果没Nginx好而已。

反向代理的优势，如下：

隐藏真实后端服务

负载均衡集群

高可用集群

缓存静态内容实现动静分离

安全限流

静态文件压缩

解决多个服务跨域问题

合并静态请求(HTTP/2.0后已经被弱化)

防火墙

SSL以及http2

动静分离

基于以上Nginx反向代理，我们还可以实现动静分离，静态请求如html、css、js等请求交给Nginx处理，动态请求分发给后端Tomcat处理。

Nginx 升级到1.9.5+可以开启HTTP/2.0时代，加速网站访问。

当然，如果公司不差钱，CDN也是一个不错的选择。

服务拆分

在这分布式微服务已经普遍流行的年代，其实我们没必要踩过多的坑，就很容易进行拆分。市面上已经有相对比较成熟的技术，比如阿里开源的Dubbo(官方明确表示已经开始维护了)，spring家族的spring cloud，当然具体如何去实施，无论是技术还是业务方面都要有很好的把控。

Dubbo

SpringCloud

服务发现——Netflix Eureka

客服端负载均衡——Netflix Ribbon

断路器——Netflix Hystrix

服务网关——Netflix Zuul

分布式配置——Spring Cloud Config

微服务与轻量级通信

同步通信和异步通信

远程调用RPC

REST

消息队列

持续集成部署

服务拆分以后，随着而来的就是持续集成部署，你可能会用到以下工具。

Docker、Jenkins、Git、Maven

图片源于网络，基本拓扑结构如下所示：

整个持续集成平台架构演进到如下图所示：

服务集群

Linux集群主要分成三大类( 高可用集群， 负载均衡集群，科学计算集群)。其实，我们最常见的也是生产中最常接触到的就是负载均衡集群。

负载均衡实现

DNS负载均衡，一般域名注册商的dns服务器不支持，但博主用的阿里云解析已经支持

四层负载均衡(F5、LVS)，工作在TCP协议下

七层负载均衡(Nginx、haproxy)，工作在Http协议下

分布式session

大家都知道，服务一般分为有状态和无状态，而分布式sessoion就是针对有状态的服务。

分布式Session的几种实现方式

基于数据库的Session共享

基于resin/tomcat web容器本身的session复制机制

基于oscache/Redis/memcached 进行 session 共享。

基于cookie 进行session共享

分布式Session的几种管理方式

Session Replication 方式管理 (即session复制)

简介：将一台机器上的Session数据广播复制到集群中其余机器上

使用场景：机器较少，网络流量较小

优点：实现简单、配置较少、当网络中有机器Down掉时不影响用户访问

缺点：广播式复制到其余机器有一定廷时，带来一定网络开销

Session Sticky 方式管理

简介：即粘性Session、当用户访问集群中某台机器后，强制指定后续所有请求均落到此机器上

使用场景：机器数适中、对稳定性要求不是非常苛刻

优点：实现简单、配置方便、没有额外网络开销

缺点：网络中有机器Down掉时、用户Session会丢失、容易造成单点故障

缓存集中式管理

简介：将Session存入分布式缓存集群中的某台机器上，当用户访问不同节点时先从缓存中拿Session信息

使用场景：集群中机器数多、网络环境复杂

优点：可靠性好

缺点：实现复杂、稳定性依赖于缓存的稳定性、Session信息放入缓存时要有合理的策略写入

java架构有哪些

Java架构：

软件架构作为一个概念，体现在技术和业务两个方面。

从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。

先说一些基本原则：

分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。

模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。

接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。从这个原则出发，软件也从微观进行了细致的规范化。

还有两个比较小但很重要的原则：

细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。其实这个原则使用很普遍，java/c++语言中的封装原则以及设计模式中的Facade（外观）模式就很能体现这个原则的精神。

依赖倒置原则随着软件结构的进一步发展,层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。这个原则有点类似于知名的好莱坞法则：Don't call us, we'll call you。

以上这些原则奠定了我们的软件架构的价值指标。但软件架构毕竟是建立在当前技术之上的。而每一代技术都有架构模式。过去的不再说了，让我们现在就来看一下当前流行的技术，以及当前我们能采用的架构。

因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。我们从三层次架构谈起：

因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。cmp和entity bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能相当完备。推荐作为持久层的首选

在业务层,因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session bean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。而spring 作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。

在用户结构层,虽然servlet/jsp/jstl/javaBean 能够实现MVC架构,但终究过于粗糙。struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。

因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致性服务acid(tool:jta/jts)、并发加锁服务concurrentlock、池化管理服务cache、访问控制服务(tool:jaas)、流程控制服务workflow、动态实现服务IOC，串行化消息服务(tool:jms)、负载平衡服务blance等。如果我们不采用重量级应用服务器(如weblogic,websphere,jboss等)及重量级组件(EJB)，我们必须自己实现其中一些服务。虽然我们大多情况下，不需要所有这些服务，但实现起来却非易事。幸运的是我们有大量的开源实现代码,但采用开源代码却常常是件不轻松的事。

随着xml作为结构化信息传输和存储地位日渐重要,一些xml文档操作工具(DOM,Digester,SAX等)的使用愈发重要,而随着xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，采用xml schema来设计xml文档格式,然后采用java binding来生成java bean 会成为主要编程模式,而这又进一步使数据中心向xml转移,使在中小数据量上,愈发倾向于以xquery为查询语言的xml数据库。最近还有一个趋势,microsoft,ibm等纷纷大量开发中间软件如(microsoft office之infopath)，可以直接从xml schema 生成 录入页面等非常实用的功能。还有web service 的广泛应用，都将对软件的架构有非常重大的影响。至于面向服务架构(SOA)前景如何，三层次架构什么时候走入历史，现在还很难定论。

aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、nanning都有其自身的严重问题:维护性很差,所以说它将很难走远。也许作为一个很好的思想，它将在web service里大展身手。

rdf,owl作为w3c语义模型的标志性的语言,也很难想象能在当前业务架构发挥太大影响。但如果真如它所声称那样，广泛地改变着信息的结构。那么对软件架构也会有深远影响。

有关架构设计的一些忠告：

尽量建立完整的持久对象层.可获得高回报

尽量将各功能分层,分块,每一模块均依赖假定的其它模块的外观

不能依赖静态数据来实现IOC模式，应该依赖数据特征接口，静态数据仅是数据特征接口实现方式之一

架构设计时xml是支持而不是依赖.但可以提供单一的xml版本的实现

从业务角度说：软件架构应是深刻体现业务内部规则的业务架构，但因为业务变化频纴，所以软件架构很难保持恒定不变，但业务的频繁变化不应是软件架构大规模频繁变化的原因，软件架构应是基于变化的架构。

一种业务有其在一段时间内稳定存在的理由(暂且不谈)，业务内部有许多用例，每一种用例都有固定的规则，每一规则都有一些可供判定的项，每一项从某一维度来观察都是可测量的，我们的架构首先必须保证完美适应每一项每一种测量方式，很多失败的架构都是因为很多项的测量方式都发生变更这种微观变化中。

每个用例都有规则，我们在作业务用例分析，常常假定一些规则是先验的，持久稳定的，然而后来的业务改变常常又证明这种看法是错误的，然而常常我们的架构已经为之付出了不可挽回的代价。大量事实证明：规则的变化常常用例变化的根本原因。所以我们的架构要尽可能适应规则的变化，尽可能建立规则模版。

每个用例都关系着不同的角色。每一个用例的产生都必然是因为角色的变更（注意：不是替换，而是增强或减弱），所以注意角色的各种可能情况，对架构的设计有举足轻重的意义。在我们当前的三层架构里，角色完美地对应接口概念。

在一个系统里很多用例都相互关联,考虑到每个用例均有可能有不同的特例，所以在架构设计中，尽量采用依赖倒置原则。如架构许可可采用消息通信模式(JMS)。这样可降低耦合度。

现在我们谈一下业务稳定存在理由对业务的影响。存在即是合理，在这里当然是正确的。业务因人而存在，所以问业务存在的理由即是问不同角色的需要这项业务的理由以及喜欢不喜欢当前业务用例的理由，所有这样的角色都应该在系统里预留。《待续》

在架构设计中有几个原则可以考虑：

用例尽量细分

用例尽量抽象

角色尽量独立

项测量独立原则

追求简单性

这里未提供相关的例子，例子会在以后的更新时提供。

业务和模式之间的关系

业务中的一些用例之间的关系常常和一些常规的模式很相似。但随着时间的演化，慢慢地和先前的模式有了分歧。这是个正常的现象。但这对系统架构却要求非常高，要求系统架构能适应一些模式的更替。在这里我们尽可能早地注意到用例之间的相互角色变化，为架构更新做好准备.

java必备架构的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java架构设计、java必备架构的信息别忘了在本站进行查找喔。