本文目录一览：
- 1、如何用java 建立一个分布式系统
- 2、什么是ESB(企业服务总线)
- 3、java用什么服务器
- 4、JavaEE性能，与外部系统集成过多或过少怎么解决？
- 5、java微服务和分布式的区别有哪些？
- 6、JAVA的基础知识
如何用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：
-结束-
什么是ESB(企业服务总线)
ESB全称为Enterprise Service Bus，即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。
java用什么服务器
Java 的应用服务器很多，从功能上分为两大类，JSP 服务器和 Java EE 服务器，也可分其他小类。
JBoss AS
在J2EE应用服务器领域，Jboss是发展最为迅速的应用服务器。由于Jboss遵循商业友好的LGPL授权分发，并且由开源社区开发，这使得Jboss广为流行。另外，Jboss应用服务器还具有许多优秀的特质。
其一，它将具有革命性的JMX微内核服务作为其总线结构；
其二，它本身就是面向服务的架构（Service-Oriented Architecture，SOA）；
其三，它还具有统一的类装载器，从而能够实现应用的热部署和热卸载能力。因此，它是高度模块化的和松耦合的。Jboss用户的积极反馈告，Jboss应用服务器是健壮的、高质量的，而且还具有良好的性能。 为满足企业级市场日益增长的需求，Jboss公司从2003年开始就推出了24*7、专业级产品支持服务。同时，为拓展Jboss的企业级市场，Jboss公司还签订了许多渠道合作伙伴。比如，Jboss公司同HP、Novell、Computer Associates、Unisys等都是合作伙伴。
JOnAS
JOnAS是一个开放源代码的J2EE实现，在ObjectWeb协会中开发。整合了Tomcat或Jetty成为它的Web容器，以确保符合Servlet 2.3和JSP 1.2规范。JOnAS服务器依赖或实现以下的Java API：JCA、JDBC、JTA 、JMS、JMX、JNDI、JAAS、JavaMail 。
JFox3.0
JFox 是 Open Source Java EE Application Server，致力于提供轻量级的Java EE应用服务器，从3.0开始，JFox提供了一个支持模块化的MVC框架，以简化EJB以及Web应用的开发! 如果您正在寻找一个简单、轻量、高效、完善的Java EE开发平台
JavaEE性能，与外部系统集成过多或过少怎么解决？
原因是高分布式系统，典型案例是电信IT环境。
在这个环境中，一个中间件领域（例如，服务总线）很少会做所有的工作，而仅仅是把一些业务“委托”给其他部分，例如产品质量，客户资料和订单管理，到其他JavaEE中间件平台或遗留系统中，如支持各种不同的负载类型和通信协议的大型机。
这样的外部系统调用意味着客户端的JavaEE应用程序触发创建或重用套接字链接从外部系统中读写数据。根据业务流程的实施和实现可以配置成同步调用或异步调用。需要注意的是，响应时间会根据外部系统的稳定状况进行改变，所以通过适当的使用超时来保护JavaEE应用程序和中间件也是非常重要的。
java微服务和分布式的区别有哪些？
这个问题已经收藏了一个多月了，一直在考虑如何回答这个问题，总结了很长时间终于有了一些感悟（之前一直都是只可意会不可言传的感觉），和大家分享一下，如果有不同的建议，欢迎大家留言指正。
分布式和微服务
首先 ，我认为微服务就是分布式框架的一种。
分布式的思想就是把一个系统的不同模块，部署在不同的服务器上，以应对高并发的问题。
SOA是一种分布式架构，把业务系统分成多个子系统，提供不同的服务，再通过服务组合、编排实现业务流程；通常在SOA架构中，ESB企业服务总线扮演了重要的角色。
微服务是SOA的升华，如果非要说点儿不同的，那么微服务更加强调服务的细分和专业，去ESB总线、去中心化，部署粒度更细，服务扩展更灵活。
微服务不只是技术架构
很多同学一说微服务，就说这是一种技术架构，有的推荐使用Dubbo，有的推荐使用Spring Cloud。
我认为，微服务不单单是一种技术架构，也涉及到了管理、组织架构。
大多数的公司，需求、开发、测试、运维都是独立的团队，这实际上是有悖于微服务快速迭代的思想；在微服务的架构下，一个服务应该是由一个团队全权负责的。
不过组织架构方面的事情，真的不是我们能说了算的。
必须要用微服务？
我觉得没有必要为了微服务，而微服务；有的公司把服务拆分，但是数据库依然是同一个库，依然是一个项目直接掉另外一个项目的接口，然后对外就宣称完成了微服务的改造...
架构设计还是要根据需求背景、团队开发能力、软硬件实力综合来考虑。
好的架构是可以进化的，而不是一步到位建成的。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
JAVA的基础知识
21.请描述一下JSP中forward与include的区别与联系
答: forward 是跳转A变成B.include是包含,A包含B.A变成B时,B会无法应用A中的属性方法等.A包含B时,B可以应用A中的属性方法等.(A与B指代"JSP页面").
22. 请描述一下Cookie与Session的关系, 并请解释一下如何实现Session的持久化？
答:Cookie与Session 都是用来存数据的(...呵呵)Cookie是存在用户这一端而Session 是存在服务器这一端.
如果用户这端允许Cookie功能并指定Cookie的生命周期则Cookie可在周期内保存.Session则服务器关闭或者Session被关闭时(比如用户登出后Session自动销毁等等情况)数据就消失.
Session的持久化
1.用Cookie来保存.
2.用数据库来保存.
3.配置conf/xml.
23. 请描述一下解析XML有哪些方法？请分别解释一下DTD和XML Schema以及二者之间的联系与区别？什么是XSL、XSLT、XPath？
答:主要有 dom解析 和 sax解析.DTD和XML Schema 都是实现对XML文件的约束(XML文件格式规则).DTD用来说明XML文档格式,Schema用来说明数据文件格式。XSL、XSLT、XPath三者都是基于XML的语言.
24. 请描述一下WSDL 、UDDI、SOAP的含义及关系
答:WSDL是网页服务描述语言.UDDI是统一描述、发现和集成协议.SOAP是简单对象访问协议.
简单的说就是上面三者都是让各种系统与各种系统之间更容易的交换信息\理解信息.
25. 请解释以下名词： SOA 、ESB 、JCA、SDO
答:SOA 是面向服务的架构.ESB是企业服务总线.JCA是J2EE平台上连接传统系统的一个技术规范.SDO是SOA的一个规范.
PS:还不快快给分!
