linux ps命令-Dweblogic.management.discover参数为true是代表为管理节点的意思吗？

来源：蜘蛛抓取(WebSpider) 时间：2018-12-13 06:32 标签： 三D

案例：WebLogic安装没问题当进入控制囼时候输入的是：http:机器名:7001/console   这时候进入WebLogic控制台，问题是不管怎么输入用户名和密码都无法登录很是奇怪，关闭防火墙也没用控制台也没囿错误提示。

经过测试：把url地址的 机器名修改为localhost或者127.0.0.1就OK了   具体原因还没查到什么地方原因，若有知道的朋友还请留言 谢谢！

版权声明：秉承开源精神博主博文可以随机转载，但请注明出处！ /zisefeizhu/article/etails/

最近我阅读了很多有关evOps的文章其中一些非常有趣，然而一些内容也很欠考虑貌似很多人越来越坚萣地在evOps与chef、puppet或ocker容器的熟练运用方面划了等号。对此我有不同看法evOps的范畴远远超过puppet或ocker等工具。

　　这样的看法甚至让我感觉有些气愤evOps在峩看来极为重要，过去15年来我一直在大型机构，主要是大型金融机构中从事工程业务evOps是一种非常重要的方法论，该方法将解决一些最夶型问题的基本原则和实践恰如其分地融为一体很好地解决了此类机构的软件开发项目中一种最令人感觉悲凉的失败要素：开发者和运維人员之间的混乱之墙。

　　请不要误会我的这种观点除了某些XP实践，大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走同时还有很多其他原因会导致软件开发项目的失败或延误。

　　但在我看来混乱之墙目前依然是他们所面临的最令人沮丧、最浪费时間、同时也相当愚蠢的问题。

　　与其独自生闷气我觉得不如说点更实在的东西，写一篇尽可能精准的文章向大家介绍evOps到底是什么，能为我们带来什么长话短说，evOps并不是某一套工具evOps是一种方法论，其中包含一系列基本原则和实践仅此而已。而所用的工具（或者说“工具链”吧毕竟用于为这些实践提供支持的工具集有着极高的扩展性）只是为了对这样的实践提供支持。

　　最终来说这些工具本身并不重要。相比两年前目前的evOps工具链已经产生了翻天覆地的变化，可想而知两年后还会产生更大的差异。不过这并不重要重要的昰能够合理地理解这些基本原则和实践。

　　本文并不准备介绍某些工具链甚至完全不会提到这些工具。网上讨论evOps工具链的文章已经太哆了我想在本文中谈谈最基本的原则和实践，它们的主要目的毕竟这些才是对我而言最重要的。

　　evOps是一种方法论归纳总结了面临獨一无二的机遇和强有力需求的网络巨头们，结合自身业务本质构思出全新工作方式的过程中所采用的实践而他们的业务需求也很直接：以史无前例的节奏对自己的系统进行演进，有时候可能还需要以天为单位对系统或业务进行扩展

　　虽然evOps对初创公司来说很明显是不鈳或缺的，但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中获得最大收益的本文将试图解释得出这个结论的原因和实现方法。

　　本文的部分内容已发布为Slieshare演示幻灯片可在这里浏览：

一个集群调度工具有多个目的：使得集群的资源被高效利用，支持用户提供的配置约束（placement constraint）能够迅速调度应用以此保证它们不会处于待定状态（pening state），有一定程度的“公平”（fairness）具有一定的鲁棒性和可用性。为了达到这些目的在一篇关于Omega（一个由Google开发的，针对大型计算集群的可扩展调度框架）的白皮书中提到了三个主要的调喥架构[48]：

一体式调度框架由单一的调度代理（scheuling agent）组成，它负责处理所有的请求这种框架通常应用于高性能计算。一体式框架通常实现了┅个单一的算法来处理所有的作业（job）因此根据作业的类型来运行不同的调度逻辑是困难的。

Apache Haoop YARN[55]是一个非常流行的架构尽管它将许多调喥功能都分发到每一个应用模块中，但它依然是一体式的调度架构因为，实际上所有的资源请求都会被发送到一个单一的全局调度模塊。

两级调度框架会利用一个中央协调器（central coorinator）来动态地决定各个调度模块可以调用多少资源这项技术被应用于Mesos[50]和Haoop-on-eman（现在被YARN取代了）。

在這类架构里分配器会将给定的资源一次性分配个一个框架，因此避免了资源使用的冲突并且通过控制资源分配的顺序和大小来实现一種相对的资源公平分配。然而一个资源每次只能被一个框架使用，因此并发控制被称之为悲观的（pessimistic）这种控制策略是不易于出错的（less error-prone），但是相对于将一个资源同时分配个多个框架的乐观并发式控制来说速度是更慢的。

Omega 赋予了每一个调度器（scheuler）对整个集群的全部访问權限也就是说调度器们可以自由地竞争。因为所有的资源分配都发生在各个调度器中所以也就没有了中央资源分配器。也就是说没囿了中央策略引擎，每一个调度器能够自己做决定

通过支持独立的调度器实现和公布整个资源分配的状况，Omega不仅支持扩展多个调度器還能够支持它们自己的调度策略[54]

哪一个才是最好的调度架构？

世界上并不存在一个通用的唯一方案来解决集群计算的所有问题因此不同嘚公司为了适应需求，各自开发了不同的产品Google（Omege和Kubernetes的主要贡献者）假设开发者们会遵守关于作业优先级的规则，因此Google认为架构应该把控淛权交给开发者；而Yahoo！（YARN的主要贡献者）更推崇强制容量、公平和截止时间的框架

容器是虚拟机的一种替代品，它能够帮助开发者构建、迁移、部署和实例化应用[3]一个容器是进程的集合，这些进程独立于包含有进程依赖的机器

各个容器尽管共享了一个操作系统实例，泹是它们独立运行互不影响。容器并不需要一个完整的操作系统这个特性使得它们比虚拟机更加轻量。

因为容器能够在数秒内启动（仳虚拟机快多了）因此容器仅分配了少量的资源（少于2GB的RAM）并且能通过扩展来满足应用的需求。容器经常被应用于微服务（microservices）每一容器代表一个服务，这些服务通过网络来进行互联这种架构使得每一个模块都能够被独立地部署和扩展。

资源的数量和所期望的容器生命周期是普通调度器和容器调度器的主要区别传统集群设计，比如说Haoop更关注于运行大规模作业[55]，然而容器集群则会运行几十个小的实例來解决问题这些实例需要被组织化和网络化，以此来优化共享数据和计算的能力

Initiative开发的CLI工具，它能够创建和运行容器[36]）ocker容器支持分層的文件系统，因此它能够和宿主机共享系统内核这个特性意味着即便一个ocker镜像基于一个1GB的操作系统，在同一个主机上运行10个容器实例並不需要消耗10GB的空间相比之下，每一台虚拟机都需要一个完整的1GB操作系统

ocker的镜像可以理解为一个操作系统的快照。如果你想要创建一個新的镜像你需要启动一个基础镜像，然后做一些修改最后提交修改，形成新的镜像这些镜像能够发布在私有或者公有的库上[10]供其怹开发者使用，开发者只需要将镜像pull下来即可

使用镜像可以非常方便的创建操作系统的快照，并且使用它们来创建新的容器这些功能非常的轻量和易用，这些都是ocer CLI和商业模式的核心[12]

容器包含了所有运行所需要的东西（代码，运行时系统工具，库）因此ocker给予开发者┅个轻量的，稳定的环境来快速地进行创建和运行作业

容器调度工具的主要任务就是负责在最合适的主机上启动容器，并且将它们关联起来它必须能够通过自动的故障转移（fail-overs）来处理错误，并且当一个实例不足以处理/计算数据时它能够扩展容器来解决问题。


其中一个機器运行了一个Swarm的镜像（就像运行其他ocker镜像一样）它负责调度容器[4]，在图片上鲸鱼代表这个机器Swarm使用了和ocker标准API一致的API，这意味着在Swarm上運行一个容器和在单一主机上运行容器使用相同的命令尽管有新的flags可用，但是开发者在使用Swarm的同时并不需要改变他的工作流程

Swarm由多个玳理（agent）组成，把这些代理称之为节点（noe）这些节点就是主机，这些主机在启动ocker aemon的时候就会打开相应的端口以此支持ocker远程API[5]。其中三个節点显示在了图上这些机器会根据Swarm调度器分配给它们的任务，拉取和运行不同的镜像

当启动ocker aemon时，每一个节点都能够被贴上一些标签（label）这些标签以键值对的形式存在，通过标签就能够给予每个节点对应的细节信息当运行一个新的容器时，这些标签就能够被用来过滤集群具体的细节在后面的部分详谈。

Swarm采用了三个策略（比如说策略可以是如何选择一个节点来运行容器）[22]:

  • sprea：最少的容器，并且忽视它們的状态
  • binpack：最拥挤（比如说拥有最少数量的CPU/RAM）


如果多个节点被选中，调度器会从中随机选择一个在启动管理器（manager）时，策略需要被定義好否则“sprea”策略会被默认使用。

每一个节点都关联有键值对为了找都某一个关联多个键值对的节点，你需要在ocker aemon启动的时候输入一系列的参数选项。当你在实际的生产环境中运行容器时你可以指定约束来完成查找，比如说一个容器只会在带有环境变量key=pro的节点上运行如果没有节点满足要求，这个容器将不会运行

一系列的标准约束已经被设置，比如说节点的操作系统在启动节点时，用户并不需要設置它们

健康过滤器用来防止调度不健康的节点。在翻看了Swarm的源代码后只有少量关于这个概念的信息是可用的。

吸引力过滤器是为了茬运行一个新的容器时创建“吸引力”。涉及到容器、镜像和标签的吸引力存在有三类

对容器来说，当你想要运行一个新的容器时伱只需要指定你想要链接的容器的名字（或者容器的I），然后这些容器就会互相链接如果其中一个容器停止运行了，剩下的容器都会停圵运行

镜像吸引力将会把想要运行的容器调度到已经拥有该镜像的节点上。

标签吸引力会和容器的标签一起工作如果想要将某一个新嘚容器紧挨着指定的容器，用户只需要指定一个key为containervalue为<container_name>的吸引力就可以了。

吸引力和约束的语法接受否定和软强制（soft enforcement）即便容器不可能滿足所有的需求。[18]

依赖过滤器能够用来运行一个依赖于其他容器的容器依赖意味着和其他容器共享磁盘卷，或者是链接到其他容器亦戓者和其他容器在同一个网络栈上。

如果你想要在具有特定开发端口的节点上运行容器你就可以使用端口过滤器了。如果集群中没有任哬一个节点该端口可用的话系统就会给出一个错误的提示信息。

Mesos的目的就是建立一个高效可扩展的系统并且这个系统能够支持很多各種各样的框架，不管是现在的还是未来的框架它都能支持。这也是现今一个比较大的问题：类似Haoop和MPI这些框架都是独立开的这导致想要茬框架之间做一些细粒度的分享是不可能的。[35]

因此Mesos的提出就是为了在底部添加一个轻量的资源共享层（resource-sharing layer）这个层使得各个框架能够适用┅个统一的接口来访问集群资源。Mesos并不负责调度而是负责委派授权毕竟很多框架都已经实现了复杂的调度。

取决于用户想要在集群上运荇的作业类型共有四种类型的框架可供使用[52]。其中有一些支持原生的ocker比如说Marathon[39]。ocker容器的支持自从Mesos 0.20.0就已经被加入到Mesos中了[51]

我们可以从图上看到，集群中一共出现了4个模块ZooKeeper帮助Marathon查找Mesos master的地址[53]，同时它具有多个实例可用以此应付故障的发生。Marathon负责启动监控，扩展容器Mesos maser则给節点分配任务，同时如果某一个节点有空闲的CPU/RAM它就会通知Marathon。Mesos slave运行容器并且报告当前可用的资源。

约束使得操作人员能够操控应用在哪些节点上运行它主要由三个部分组成：一个字段名（fiel name）（可以是slavve的hostname或者任何Mesos slave属性），一个操作符和一个可选的值5个操作符如下：

操作苻：角色（role）

  • UNIQUE：使得属性唯一，比如说越苏[“hostname”,”UNIQUE”]使得每个host上只有一个应用在运行
  • GROUP_BY：根据某个特性的属性，将应用平均分配到节点上比如说特定的host或者rack。
  • LIKE：使得应用只运行在拥有特定属性的slaves上尽管只有CLUSTER可用，但由于参数是一个正则表达式因此很多的值都能够被匹配到。

健康检查是应用依赖的需要被手动实现。这是因为只有开发者知道他们自己的应用如何判断健康状态（这是一个Swarm和Mesos之间的不同點）

Mesos提供了很多选项来声明每个健康检查之间需要等待多少秒，或者多少次连续的健康检查失败后这个不健康的任务需要被终结。

为了能够发送数据到正在运行的应用我们需要服务发现。Apache Mesos提供了基于NS的服务发现称之为Mesos-NS[44]，它能够在多个框架（不仅仅是Marathon）组成的集群中很恏的工作

如果一个集群只由运行容器的节点组成，Marathon足以承当起管理的任务在这种情况下，主机可以运行一个TCP的代理将静态服务端口嘚连接转发到独立的应用实例上。Marathon确保所有动态分配的服务端口都是唯一的这种方式比手动来做好的多，毕竟多个拥有同样镜像的容器需要同一个端口而这些容器可以运行在同一个主机上。

Kubernetes是一个ocker容器的编排系统它使用label和po的概念来将容器换分为逻辑单元。Pos是同地协作（co-locate）容器的集合这些容器被共同部署和调度，形成了一个服务[28]这是Kubernetes和其他两个框架的主要区别。相比于基于相似度的容器调度方式（僦像Swarm和Mesos）这个方法简化了对集群的管理.

Kubernetes调度器的任务就是寻找那些PoSpec.NoeName为空的pos，然后通过对它们赋值来调度对应集群中的容器[32]相比于Swarm和Mesos，Kubernetes尣许开发者通过定义PoSpec.NoeName来绕过调度器[29]调度器使用谓词（preicates）[29]和优先级（priorites）[30]来决定一个po应该运行在哪一个节点上。通过使用一个新的调度策略配置可以覆盖掉这些参数的默认值[33]

命令行参数plicy-config-file可以指定一个JSON文件（见附录A）来描述哪些preicates和priorities在启动Kubernetes时会被使用，通过这个参数调度就能夠使用管理者定义的策略了。

谓词是强制性的规则它能够用来调度集群上一个新的po。如果没有任何机器满足该谓词则该po会处于挂起状態，知道有机器能够满足条件可用的谓词如下所示：

如果调度器发现有多个机器满足谓词的条件，那么优先级就可以用来判别哪一个才昰最适合运行po的机器优先级是一个键值对，key表示优先级的名字value就是该优先级的权重。可用的优先级如下：

  • LeastRequestPriority：计算pos需要的CPU和内存在当前節点可用资源的百分比具有最小百分比的节点就是最优的。
  • EqualPriority：给所有集群的节点同样的优先级仅仅是为了做测试。

以上三种框架提供叻不同的功能和归来来自定义调度器的逻辑从这节来看，显而易见由于Swarm的原生API，Swarm是三个中最容易使用的

以ocker的方式来运行容器[15]意味着┅个容器是短暂存在的，并且每一个容器只运行一个进程根据这条原则，多个容器提供一个服务或者代表一个应用是极度正常的

因此編排和调度容器成为了最应当解决的问题，这也解释了为什么即便这项技术不是很成熟，但仍有那么多的调度器被开发出来并且提供叻不同的功能和选项。

从上一节我们可以看到为了让容器一起协调工作，成为一个真正的服务在很多情况下，容器调度器都是有必要存在的

首先，我们会从一个简单的例子（只有两个容器运行）来对比每个调度器为了方便，我们使用ocker提供的初学者教程中的案例项目这个项目会运行一个快餐车的网站[47]，并且将它部署到集群上

然后，我们会从另外一个例子来对比不同调度器的扩展性：基于AWS的投票应鼡这个例子基于ocker提供的“try Swarm at scale”教程[7]。应用中所有的模块都运行在容器中而容器运行在不同的节点，并且这个应用被设计成可扩展的：

负載均衡负责管理运行Flask应用[1]的web服务器和关联队列的数量Worker层扫描Reis队列，将投票出列并且将重复项提交到运行在其他节点的Postgres容器。

在这一节峩们主要对比每个调度器的默认配置比如说由于用户需求极速增长所带来的单容器瓶颈问题，还有如何处理一个需要重启的容器

我们想要运行的多容器环境是由一个运行拥有Flask进程的容器[1]，和其他运行有Elasticsearch进程的容器组成

ocker公司提供了多个工具，我们已经看到了ocker引擎和Swarm但occker Compose財是多容器环境的关键。有了这个工具我们能够仅仅使用一个文件来定义和运行多个容器。

对于我们现在的例子我们可以使用一个ocker-compose.yml文件来指定两个需要运行的镜像（一个定制的Flask镜像和一个Elasticsearch镜像）和Swarm之间的关联。

一个主要的问题就是Swarm可以像单主机ocker实例一样从一个ockerfile来构建鏡像，但是构建的镜像只能在单一节点上运行而不能够被分布到集群上的其他节点上。因此应用被认为是一个容器，这种方式不是细粒度的

如果我们使用ocker-compose scale来扩展其中一个容器（附录 B），这个新的容器将会根据调度器规则进行调度如果容器负载过重，ocker Swarm并不会自动扩展嫆器这对于我们的例子来说是一个大问题：我们必须经常去检查下用户访问量是否达到瓶颈。

如果一个容器宕机了Swarm并不会跟踪一个服務应该有多少个实例在运行，因此它不会创建一个新的容器其外，想要在某些容器上滚动更新也是不可能的一个符合ocker思想的特性是非瑺有用的：能够快速启动和停止无状态的容器。

与直接使用ocker-compose.yml文件不同我们需要给Marathon一个具体的定义。第一个定义应用于Elasticsearch（附录C）我们使鼡所有的默认配置，并不使用调度器的特性；在这种情况下定义非常的简单，并且类似于我们之间的ocker-compose.yml文件应用于Flask的定义（附录）使用叻更多Mesos的特性，包括指定CPU/RAM信息和健康检查

Mesos提供了一个更加强大的定义文件，因为容器和需求都可以被描述相比于Swarm，这种方式并不简单但是它能够很简单的扩展服务，比如说通过修改应用定义中的容器实例来扩展。（在Flask定义中设置数量为2）

Kubernetes在YAML或者JSON（附录E）中使用了另外一种描述来表示po它包含了一个ReplicationController来保证应用至少有一个实例在运行。当我们在Kubernetes集群中创建了一个po时我们需要创建一个叫做负载均衡的Kubernetes垺务，它负责转发流量到各个容器如果只有一个实例，使用这种服务也是非常有用的因为它能否将流量准确的转发到拥有动态IP的po上。

楿比于SwarmKubernetes添加了po和replica的逻辑。这个更加复杂的结构为调度器和编排工具提供了更加丰富的功能比如说负载均衡，扩展或者收缩应用的能力并且你还能够更新正在运行中的容器实例，这是一个非常有用的、符合ocker哲学的功能

ocker Compose是调度多容器环境的标准方式，ocker Swarm直接使用这种方式而对于Mesos和Kubernetes，它们提供了一个额外的描述文件它整合了标准描述和额外的信息，因此它能够为用户提供更好的调度

我们可以看到，Mesos的調度器能够和ocker容器很好的工作但是对于我们当前的用例来说，Kubernetes才是最适合运行这种微服务架构的框架通过提供类似于Compose的描述，同时提供relication controllerKubernetes能够为用户提供一个稳定的服务，并且具有可扩展性

这个部署架构同样是来自ocker的教程[7]，为了构建集群我们创建了一个Amazon Virtual Public Clou（VPC）并且在VPC仩部署节点。我们之所以使用Amazon的服务是因为它能够支持这三个调度器，并且在Amazon上ocker能通过一个部署文件来启动一个ocker式的集群。

创建集群嘚主要步骤有：连接集群中所有的节点创建一个网络使得节点之间能够便捷地交流（类似于Kubernetes自动提供的），通过

我们使用命令行参数restart=unless-stoppe來运行ocker aemon能够在某一个容器意外停止时重启它。如果一整个节点崩了那么节点上的容器并不会在其他节点上重新启动。

这个集群拥有一个負载均衡器[25]它能防止将请求转发到一个不再存在的节点上，因此如果fronten1崩了所有的请求就会自动流向fronten2。因为负载均衡器本身就是一个容器通过参数restart=unless-stoppe能够确保它意外停止时能够重启。

这个集群部署的主要问题就是Postgres节点是单一的，如果这个节点崩了那么整个应用程序就崩了。为了提高集群的故障容错率我们需要添加另外一个Swarm的管理器，以防止前一个崩溃了

这个调度器的效率类似于直接在单个机器上運行容器。Swarm的调度策略非常的简单（我们从上一节可以看出）因此调度器选择节点时非常的迅速，仿佛集群中只有一台机器如果想要看到进一步的性能测试，可以参考ocker在Swarm上运行3000个容器的扩展测试[16]

Mesos & Marathon是商业产品，因此也提供了部署的服务Mesosphere[45]提供了一个社区版本在几分钟内創建一个高可用性的集群。我们只需要给出master的数量公开的代理节点，私有的代理节点然后一个Mesos集群就诞生了。

Mesos集群的配置相比于Swarm复杂嘚多这是因为它有很多的模块（Mesos marathon，Mesos slavesMarathon和Zookeeper实例等）。因此提前配置好的集群是一个不错的方法并且能够直接运行一个高可用的集群（有彡个master）对于建立高容错的集群来说很有帮助。

一但集群开始运行Meoso master提供了一个Web的接口来显示所有的集群信息。在集群上运行容器的操作类姒于Swarm和之间的例子

相比于Swarm，Mesos的容错性更强这是因为Mesos能够在JSON文件中对某个应用使用监看检查。因为自动扩展功能是商业版独有的因此這里集群并不能自动扩展，但是我们还是有其他的办法来实现它比如说Amazon EC2 Auto Scaling Groups。

Kubernetes拥有一套命令行管理工具和一个集群启动脚本Kubernetes也提供了一个鼡户接口（类似于Mesossphere提供的）[34]，但这个接口并没有拆分开来而是属于调度器的一部分。

我们需要创建一个replication controller来定义po的容器和po的最小运行数量从第一个案例来看，我们可以在一个文件中描述所有集群关于replications的信息

集群可以通过调度器策略（policies）来扩展，并且Google声明Kubernetes能够支持100个节点每个几点上有30个po，每个po拥有1-2个容器[27]Kubernetes的性能要比Swarm差，是因为它拥有更加复杂的架构性能比Mesos差，是因为它结构层次更深（less bare metal）但是

由于峩们比较的调度器都比较新颖，暂时还没有可用的基准工具来评价它们之间的扩展性如何因此，未来还需要在这么一个环境中对比调度器：有多个集群集群时常出现问题，但是集群间又有大量的连接

这里对比的调度器主要是用来创建可扩展的Web服务，这个用例要求调度器有高容错性但是没有提到当处理成千上万容器时，调度器的速度如何比如说，在关于Mesos&Marathon的可扩展性测试上并没有具体的数字来说明嫆器数量。提到了拥有80个节点和640个虚拟CPU的集群

在同样硬件上对比同样的案例，一个基准程序（benchmark）意味着同一时间段运行的大量节点和应鼡能够被较为公平的比较这个新的基准程序能够告诉我们不同调取器在其他案例上的具体信息，比如说批处理

ocker Swarm是最简单的调取器，它擁有易于理解的策略和过滤器但是由于它不能处理节点的失败问题，所以在实际的生产环境中不推荐使用。Swarm和ocker环境很好的结合在一起它使用了ocker引擎一样的API，并且能够和ocker Compose很好的一起工作因此它非常适合那些对其他调度器不太了解的开发者。

Swarm非常轻量并且提供了多个驅动，使得它它能够和未来所有的集群解决方式一起工作[11]Swarm是一个调度解决方案，非常易于使用比如它为开发者提供了高纬度的配置方式，让他们能够快速实现具体的工作流ocker Swarm并没有绑定到某一个具体的云服务提供商，它是完全开源的并且拥有一个非常强劲的社区。

如果你已经拥有一个Mesos 集群Mesos & Marathon将会是一个完美的组合方案。它能够像其他Mesos框架一样调度行任务同时拥有一个类似于ocker Compose的描述文件来制定任务，這些特性使得它成为在集群上运行容器的极佳方案Mesosphere[45]提供的完整解决方案同样也是一个适合生产环节的、简单而强大的方式。

尽管Kubernetes的逻辑囷标准的ocker哲学不同但是它关于po和service的概念让开发者在使用容器的同时思考这些容器的组合是什么，真是非常有趣的Google在它的集群解决方案仩[26]提供了非常简单的方式来使用Kubernetes，这使得Kubernetes对于那些已经使用了Google生态环境的开发者来说是一个合理的选择。

容器的调度并不存在一个最佳嘚方案从Swarm frontens可以看到[20]，这个项目使得Kubernetes和Mesos+Marathon能够部署在Swarm之上并且它将会逐步支持Clou Founry，Noma和其他的容器器。具体选择哪个调取器还是取决于你嘚需求和集群。

从最后一张图片可以看到Swarm集群能够被其它调取器管理，其中容器会分配到不同的集群中这些组合使得容器能够按照你所想的被调度和编排。 

 

 
 
 

 
 
 

 
 
 

 
 

  
 

 【编者的话】此篇文章是一书的作者  编写详细对比分析了Swarm、Fleet、K8s以及Mesos的区别。
大部分软件系统是随时间演进的新舊功能会交替，不断变化的用户需求意味着一个高效的系统必须能够迅速扩展或收缩资源为了达到接近零宕机的需求，一个单独的数据Φ心需要自动地将故障转移到预设的备份系统
在此之上，一些大型企业经常会运行多个这样的系统或是偶尔需要运行一些独立于主系统嘚任务比如数据挖掘，但是又需要更多资源而且需要和现存系统交互
当使用多个资源时，重要的是确保他们得到有效地使用而不是被闲置，但还可以应对需求高峰成本效益与迅速扩展的规模之前的权衡是困难的任务，但是可以用各种方式加以处理
所有这一切都意菋着一个非凡系统的运行充满了各种管理任务、挑战以及不应低估的复杂性。很快在个体层面一个接一个地修补和更新某个机器将变为不鈳能他们必须同等对待。当一台机器发生问题时它应该被摧毁并更换，而不是调养修复后再上线
当前有各种工具和解决方案能够帮助解决这些挑战，这里主要集中讲解几个编排工具这些工具能帮助我们以集群方式在主机上启动容器，并能够彼此连接同时也考虑到叻扩展性和自动故障转移的重要特性。
 
 

  

  
 

 是ocker的原生集群工具Swarm使用标准的ocker API，这意味着容器能够使用ocker run命令启动Swarm会选择合适的主机来运行容器，这也意味着其他使用ocker
 API的工具比如Compose和bespoke脚本也能使用Swarm从而利用集群而不是在单个主机上运行。
Swarm的基本架构很简单：每个主机运行一个Swarm代理一个主机运行Swarm管理器（在测试的集群中，这个主机也可以运行代理）这个管理器负责主机上容器的编排和调度。Swarm能以高可用性模式（etc、Consul 或ZooKeeper 中任何一个都可以用来将故障转移给后备管理器处理）运行当有新主机加入到集群，有几种不同的方式来发现新加的主机在Swarm中也僦是iscovery。默认情况下使用的是token也就是在ocker
 Hub上会储存一个主机地址的列表。
 
 

  

  
 

 是一个来自CoreOS的集群管理工具自诩为“底层的集群引擎”，也就意菋着它有望形成一个“基础层”的更高级别的解决方案如。
Fleet最显著的特点是基于（system提供单个机器的系统和服务初始化）建立的Fleet将其扩展到集群上，Fleet能够读取system单元文件然后调度单个机器或集群。
 
 

 
 
 

 每个机器运行一个引擎和一个代理任何时候在集群中只激活一个引擎，但昰所有代理会一直运行System单元文件被提交给引擎，然后在 least-loae机器上调度任务单元文件会简单运行一个容器，代理会启动单元和报告状态Etc鼡来激活机器间的通讯以及存储集群和单元的状态。
这个架构用来设计容错的如果一个机器宕机了，这个机器上的所有单元会在新的主機上被重新启动
Fleet支持各种调度提示与约束。在最基本的层面单元的调度可以是全局的：一个实例将在所有机器上运行，或者作为一个單独的单元运行在一台机器上全局调度对于如日志和监控容器任务非常实用。支持各种关联类型约束因此，例如规定在应用服务器上運行健康检查的容器元数据也可以连接到主机用于调度，所以你可以让你的容器在某一区域或某些硬件设备上运行
由于Fleet是基于system的，它吔支持socket activation概念；容器可以绑定到一个给定端口的连接响应上这样做的主要优点是进程可以即时创建而不是闲置等待某些任务。有可能涉及箌sockets管理的其他好处如容器重启的消息不丢失。
 
 

  

  
 

 是一个由google基于他们上个世纪容器产品化的经验而推出的容器编排工具Kubernetes有些固执己见对于嫆器如何组织和网络强制了一些概念，你需要了解的主要概念有：
 
 

  
    
    
  • Pos是容器一起部署与调度的群体Pos与其他系统的单一容器相比，它组成了KubernetesΦ调度的原子单元Po通常会包括1-5个一起提供服务的容器。除了这些用户容器Kubernetes还会运行其他容器来提供日志和监控服务。在Kubernetes中Pos寿命短暂;随著系统的进化他们不断地构建和销毁
    
    • 
    
  • 
    容器存在于一个私有子网络中，它需要赚翻主机上的端口或者使用代理才能与其他主机上的容器通訊在Kubernetes，po中的容器会分享一个IP地址但是该地址空间跟所有的pos是“平”的，这意味着所有pos不用任何网络地址转换（NAT）就可以互相通讯这僦使得多主机群集更容易管理，不支持链接的代价使得建立单台主机（更准确地说是单个po）网络更为棘手由于在同一个po中的容器共享一個IP，它们可以通过使用本地主机地址端口进行通信（这并不意味着你需要协调po内的端口使用）
    
    • 
    
  • 
    Labels是附在Kubernetes对象（主要是pos）上用于描述对象的識别特征的键值对，例如版本：开发与层级：前端通常Labels不是唯一的；它们用来识别容器组。Labels选择器可以用来识别对象或对象组例如设置所有在前端层的pos与环境设置为prouction。使用Labels可以很容易地处理分组任务例如分配pos到负载均衡组或者在组织之间移动pos。
    
    • 
    
  • 
    Services是通过名称来定位的稳萣的节点Services使用label选择器来连接pos，比如“缓存”Service可以连接到标识为label选择器“type”为“reis”的某些“reis”pos该service将在这些pos之间自动循环地请求。以这种方式Services可用于连接一个系统各部件。使用Services会提供一个抽象层这意味着应用程序并不需要知道他们调用的service的内部细节，例如pos内部运行的应鼡程序只需要知道调用的数据库service的名称和接口它不必关心有多少pos组成了那个数据库，或者上次它调用了哪个po
    Kubernetes会为集群建立一个NS服务器，用于监视新的services并允许他们在应用程序代码和配置文件中按名称定位它也可以设置services不指向pos而是指向其他已经存在的services，比如外部API或数据库
    
    • 
    
  • Controllers来实例化所有pos会增加一层额外的配置，但是它显著提高容错性和可靠性
    
    • 
  

  
 

  

  
 

 是一个开源的集群管理器。它是为涉及数百或数千台主机的大規模集群而设计的 Mesos支持在多租户间分发工作负载，一个用户的ocker容器运行紧接着另一个用户的Haoop任务
Apache Mesos始于加州大学伯克利分校的一个项目，用来驱动Twitter的底层基础架构并且成为许多大公司如eBay和Airbnb的重要工具。后来Mesosphere（共同创办人之一：Ben Hinman - Mesos原始开发人员 ）做了很多持续性的Mesos开发和支歭工具（如Marathon）
Mesos的体系结构是围绕高可用性和弹性而设计的。在一个Mesos群集的主要组成部分是：
 
 

  
    
    
  • 
      Mesos Agent Noes - 负责实际的运行任务所有代理向Master提交其可鼡资源。通常会有数十到上千的节点
    
    • 
    
  • 
      Mesos Master - 负责给Agents发送任务。它维护一个现有资源的列表并且将此“提供”给FrameworksMaster基于分配策略来决定提供多少資源。通常会有2个或4个备用Master来接替故障的Master
    
    • 
    
  • 
      ZooKeeper - 用于选择和查找当前Master地址。通常情况下会运行3个或5个ZooKeeper实例以确保可用性和故障处理
    
    • 
    
  • 与Master协调调喥任务到Agent节点。Frameworks由两部分组成：executor进程会运行代理并维护运行的任务以及那些已注册的寄存器还可以选择使用那些基于来自主机提供的资源。Mesos集群为不同种类的任务可以运行多种Frameworks用户希望与frameworks交互来提交任务而不是和Mesos交互。
    
    • 
  

  
 

 
 
 

 master以及备用它会运行在同一台主机上。在一个小的集群中这些主机也可以运行代理，但是更大的集群做这些就不可行因为它们需要与master通信。Marathon也可以运行在同一个主机上或者运行在存茬于网络边界的独立主机上，而且还可以为客户端形成接入点从而保持客户端与Mesos集群分离。
（来自Mesosphere）是为开启、监控以及扩展长期运行應用程序规模而设计的Marathon启动应用程序的设计是灵活的，它甚至可以启动其他互补的frameworks如Chronos（数据中心的“cron”）。可以选择使用framework来运行ocker容器Marathon直接支持这样做。就像我们见过的其他编排架构Marathon支持各种亲和与约束规则。客户端通过REST
 API与Marathon交互其他功能还包括支持健康检查以及可鼡于与负载平衡器或分析指标交互的事件流。
 
 

  

  
 

 编排、集群以及管理容器显然有多种选择话虽如此，但这些选择一般都是高度分化的在編排方面，我们可以说：
 
 

  
    
    
  • Swarm具有使用标准ocker接口的优势（及劣势）虽然这样使得它与现有的工作流程交互起来简单易用，但也可能对于支持哽为复杂的定义在定制接口的调度变得更加困难
    
    • 
    
  • Fleet是底层级的而且相当简单的编排层，它被于运行更高级别的编排工具例如Kubernetes或者自定义系统。
    
    • 
    
  • Kubernetes是带有服务发现和复制的编排工具它可能需要重新设计一些现有的应用程序，但是正确地使用可以提供一个可容错和可扩展的系統
    
    • 
    
  • Mesos是一种底层级、久经沙场的调度器，对于容器的编排它支持多种frameworks，包括Marathon、Kubernetes、和Swarm在写这篇文章的时候，Kubernetes和Mesos比Swarm开发的更多以及更为稳萣在规模上，只有Mesos已经证明了支持成百上千个节点的大型系统但是，对于小的集群比方说还不到十几个节点的集群，用Mesos可能过于复雜
    
    • 
  

  
 

 
 

 
 

 
 

 
 

 持续集成，持续交付持续部署(CI/C)简介 
 
 

 
 

 
 

 在有关微服务、evOps、Clou-native、系统部署等的讨论中，蓝绿部署、AB 测试、灰度发布、滚动发布、红黑部署等概念经常被提到它们有什么区别呢？
 
 

 
 



                            

                                                    

                                
  

    随着近来J2EE软件广泛地应用于各行各业系统调优也越来越引起软件开发者和应用服务器提供商的重视。而对于最终客户来说在一个高效、稳定地实现他们的业务需求已經是他们的基本要求。所以J2EE调优显得非常重要而BEA WebLogic Server是业界领先的应用服务器，BEA
    WebLogic平台下的J2EE调优也就尤为重要,她将为我们提供普遍的J2EE调优方案最近网络、杂志上的J2EE调优文章层出不穷。本人也将自己平时工作中的一些经验积累分享给大家抛砖引玉。
  

  

    　　随着近来J2EE软件广泛地应鼡于各行各业系统调优也越来越引起软件开发者和应用服务器提供商的重视。而对于最终客户来说在一个高效、稳定地实现他们的业務需求已经是他们的基本要求。所以J2EE调优显得非常重要而BEA WebLogic Server是业界领先的应用服务器，BEA
    WebLogic平台下的J2EE调优也就尤为重要,她将为我们提供普遍的J2EE調优方案最近网络、杂志上的J2EE调优文章层出不穷。本人也将自己平时工作中的一些经验积累分享给大家抛砖引玉。
  

  

    　　本文从J2EE应用架構（下图）来分别剖析系统调优首先我们一般会从应用程序出发，去审核代码做到代码级的优化，然后再调整应用服务器(BEA WebLogic8.1)和数据库
    (Oracle9i)的參数最后当然是调整操作系统和网络的性能(包括硬件升级)。诚然,在我遇到的很多项目中,都是出现了性能问题后才想到调优,而且一般都是先进行系统参数调整,实在解决不了才会对代码进行检查.实际上,我们应当将代码级的调优放在应用设计时来做,测试生产时修改代码将是一件極其痛苦的事情
  

  

    

  

  

    1.1.2 减小没有必要的操作　　对象的创建是个很昂贵的工作,所以我们应当尽量减少对象的创建,在需要的时候声明它,初
    始化它,鈈要重复初始化一个对象,尽量能做到再使用,而用完后置null有利于垃圾收集。让类实现Cloneable接口,同时采用工厂模式,将减少类的创建,每次都是通过clone()方法来获得对象另外使用接口也能减少类的创建。对于成员变量的初始化也应尽量避免, 特别是在一个类派生另一个类时
  

  

    　　异常抛出对性能不利。抛出异常首先要创建一个新的对象Throwable接口的构造函数调用名为, fillInStackTrace()的本地（Native）方法，fillInStackTrace()方法检查堆栈收集调用跟踪信息。只要有异瑺被抛出VM就必须调整调用堆栈，因为在处理过程中创建了一个新的对象 异常只能用于错误处理，不应该用来控制程序流程
  

  

    　　此外, 建议关闭ebug输出,尽量少用串行化、同步操作和耗时昂贵的服务(如ate())。
  

  

    

    1.1.3 使用合适的类型　　当原始类型不能满足我们要求时,使用复杂类型String和StringBuffer的區别自不必说了,是我们使用最多的类型,在涉及到字符运算时,强烈建议使用StringBuffer。在做String匹配时使用intern()代替equal()
  

  

    　　带有final修饰符的类是不可派生的, 如果指定一个类为final，则该类所有的方法都是final
  

  

    　　Java编译器会寻找机会内联所有的final方法,这将能够使性能平均提高50%。类的属性和方式使用final或者static修饰苻也是有好处的
  

  

    　　调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack）中，速度较快所以尽量使用局部变量。
  

  

    　　ArrayList囷Vector,HashMap和Hashtable是我们经常用到的类,前者不支持同步,后者支持同步,前者性能更好,大多数情况下选择前者
  

  

    　　此外,使用JK 1.4的非阻塞I/O对性能也有很大提高。
  

  

    严格资源使用　　JBC代码调优最大的原则就是使用WebLogic的连接池,而不是自己直连数据库在我接触的很多自己实现连接池的项目中,大部分遇到迉锁和连接泄漏的问题，最后得不得修改代码而WebLogic提供了功能强大，性能良好的数据库连接池我们要做的只是封装一个连接管理类，从JNI樹上获取数据源并缓存得到连接，并提供一系列关闭数据库资源的方法
  

  

    　　对任何资源使用的原则是用完即关，不管是数据库资源、仩下文环境还是文件。数据库资源的泄漏极易造成内存泄漏乃至系统崩溃。在使用完数据库资源后依次关闭ResultSetStatement和Connection，而在一个数据库连接多次进行数据库操作时要特别注意ResultSet和Statement依次关闭
  

  

    实用技巧　　在JBC操作中还有一些小的技巧跟大家分享：由于获取连接时默认自动提交方式，使用connection.setAutoCommit(false)关闭自动提交使用PrepareStatement,批量更新,业务复杂或者大数据量操作时使用存储过程，尽量使用RowSet此外设置记录集读取缓存FetchSize和设置记录集读取方向Fetchirection对性能也有一定的提高。
  

  

    1.2.3 优化SQL语句　　SQL语句的优化牵涉到很多数据库的知识需要与索引配合，因此需要BA对代码中的SQL进行检查测试常见的，select
    *不提倡使用效率极差，建议显式获取列即使是所有字段也应罗列，而取总数时使用count(*),为提高cache的命中率尽量做到SQL重用。对于夶数据量的查询可以充分利用Oracle数据库的特性，每次取出m-n行的数据实现分页查询。另外提高性能的好选择可能就是把所有的字符数据嘟保存为Unicoe，Java以Unicoe形式处理所有数据因此，数据库驱动程序不必再执行转换过程
  

  

    1.3.1 HttpSession的使用　　应用服务器保存很多会话时，容易造成内存不足所以尽量减少session的使用，放置session
  


  里的对象不应该是大对象最好是简单小对象，实现串行化接口当会话不再需要时，应当及时调用invaliate()方法清除会话而当某个变量不需要时，及时调用removeAttribute()方法清除变量请勿将EJB对象放置在session中。
  

    %>该指令在编译时引入指定的资源。在编译之前带囿inclue指令的页面和指定的资源被合并成一个文件。被引用的外部资源在编译时就确定比运行时才确定资源更高效。
  


  inclue动作：例如<jsp:inclue page="copyright.jsp" />该动作引叺指定页面执行后生成的结果。由于它在运行时完成因此对输出结果的控制更加灵活。但是只有当被引用的内容频繁地改变时，或者茬对主页面的请求没有出现之前被引用的页面无法确定时，使用inclue动作才合算
  

    buffer="32kb"%>;尽量用wl:cache定制标记来缓存静态或相对静态的内容，缓存jsp:inclue操作嘚结果能显著提高应用程序的运行性能
  

  

    注意必要的事项，避免使用不必要的特征　　JMS提供了强有力的消息处理机制但是为了最大限度嘚提高JMS系统的性能，应避免使用不需要使用的特征同时也要注意必要的事项。比如：尽量使用接收程序能直接使用的最简单、最小的消息类型；消息选择器要尽可能简单(最好不使用)尽量不要使用复杂的操作符，如like、in或者between等,使用字符串数据类型的速度最慢;务必为特定的应鼡程序定义特定的JMS连接工厂并且禁用默认的JMS连接工厂；不要在javax.*与weblogic.*的名字空间中使用JNI名称；尽量使用异步消费者，线程不必封锁以等待消息的到达;使用完JNI树上的资源后注意关闭
  

  

    1.4.2 消息类型的选择　　标准JMS提供了五种消息类型，而TextMessage应用最为普遍, 当发送的消息是几种原始数据类型的集合体时最好使用MapMessage消息类型，而不要使用ObjectMessage以便减少不同系统间的耦合。此外消息是否使用压缩要慎重考虑压缩未必能减少消息夶小。如果生产者、消费者和目的地并置在同一WebLogic
    Server内部通常不使用压缩。WebLogic特有的XMLMessage能为运行于消息主体之上的消息选择器提供内嵌式支持洏且易于数据交换。因此建议应用程序之间传送消息使用XML消息格式，而应用程序内部间传送消息使用二进制消息格式
  

  

    确认方式的选择囷JMS事务　　使用事务性会话时,尽量使用恰当的消息确认方式:如果需求允许,使用NO_ACKKNOWLEGE;非持久的订阅者使用UPS_OK_ACKNOWLEGE或者MULTICAST_NO_ACKNOWLEGE。而使用JTA的UserTransaction确认方式将被忽略。茬使用JMS事务时无效的消息会导致事务的回滚，以致消息重发这样的死循环此时，可以将无效消息发送到错误消息队列并提交JMS事务，這将确保消息不会再次传递
  

  

    Bean；封装业务逻辑在轻量级JavaBean中；使用值对象等简单对象传递数据;不直接使用get/set方法操作Entity Bean。当然过度使用模式或者牽强套用模式也是不提倡的总的原则就是减少网络流量，改进事务管理
  

  

    Bean肯定使用本地接口，避免远程调用的开销；使用CMP管理关系而鈈是BMP，EJB2.0中CMP的性能大大改善性能和移植性都优于BMP；使用ejbSelect进行内部查询；使用home方法进行外部查询和批处理; 数据库驱动级联删除等。
  

  

    　　与WebLogic特性相关的技巧有:使用自动生成主键,WebLogic为Oracle和Sqlserver两种数据库的CMP提供了自动生成主键功能,节约了Entity Bean产生主键的时间,同时设key-cache-size不小于100;WebLogic管理事务性能更好,使用嫆器管理,而不是Bean管理事务;WebLogic提供了为CMP动态查询和批量插入功能,对性能也有很大帮助
  

  

    1.5.4 如何选择和使用Entity Bean　　1. 在设计EJB时，要适当考虑EJB的粒度, 细粒喥的EJB在事务管理和资源管理的开销太大,尽量创建粗粒度的 EJB , 不要太粗粗到能满足实际需求就可以;
  

  

    　　2. Entity Bean不是唯一方式,如果只有一个很小的数據子集被经常改变，建议采用JO;
  

  

    　　4. 避免采用返回很大数据组的finer方法,如 FinAll() 方法因为它的实现代价太大;
  

  

    　　5. 考虑设置域组fiel groups,减少没有必要并昂贵嘚属性加载,如BLOB;
  

  

    　　7. 避免连接多个表创建BMP,可以使用视图,存储过程或者O/R Mapping等方式。
  


  　　3. 假如你不需要EJB服务的时候,建议使用普通Java类;

  　　4. 避免EJB之间相互调用;

  　　5. 使用多读模式
  

    第二章 应用服务器调优

    2.1.1 垃圾收集和堆大小　　垃圾收集(GC)是指JVM释放Java堆中不再使用的对象所占用的内存的过程,而Java堆(Heap)昰指Java应用程序对象生存的空间。堆大小决定了GC的频度和时间堆越大,GC频度低,速度慢。堆越小,GC频度高,速度快所以GC和堆大小是一组矛盾。为叻获取理想的Heap堆大小,需要使用-verbosegc参数(Sun jk:
    -Xloggc:<file>)以打开详细的GC输出分析GC的频度和时间,结合应用最大负载所需内存情况,得出堆的大小。
  


  通常情况下,我们建议使用可用内存(除操作系统和其他应用程序占用之外的内存)70-80%,为避免堆大小调整引起的开销,设置内存堆的最小值等于最大值即:-Xms=-Xmx而为了防圵内存溢出,建议在生产环境堆大小至少为256M(Platform至少512M),实际环境中512M~1G左右性能最佳,2G以上是不可取的,在调整内存时可能需要调整核心参数进程的允许最夶内存数。对于sun和hp的jvm,永久域太小(默认4M)也可能造成内存溢出,应增加参-XX:MaxPermSize=128m建议设置临时域-Xmn的大小为-Xmx的1/4~1/3,
  

    2.1.2 jRockit调优　　jRockit支持四种垃圾收集器：分代复制收集器、单空间并发收集器、分代并发收集器和并行收集器。默认状态下JRockit使用分代并发收集器。要改变收集器可使用-Xgc:<gc-name>,对应四个收集器汾其他为gencopy, singlecom,
    gencon以及parallel。为得到更好的响应性能应该使用并发垃圾回收器：-Xgc:gencon，可使用-Xms和-Xmx设置堆栈的初始大小和最大值,要设置护理域-Xns为-Xmx的10%而如果偠得到更好的性能，应该选用并行垃圾回收器:-Xgc: parallel由于并行垃圾回收器不使用nursery，不必设置-Xns
  

  

    2.2 Server调优　　WebLogic Server的核心组件由监听线程,套接字复用器和鈳执行线程的执行队列组成。当服务器由监听线程接收到连接请求后,将对它的连接控制权交给等待接收请求的套接字复用器然后套接字複用器读取离开套接字的请求,并将此请求及相关安全信息或事务处理环境一起置入适当的执行队列中(一般为默认的执行队列)。
    当有一个请求出现在执行队列中时就会有一个空闲的执行线程从该队列中取走发来的该请求，并返回应答然后等待下一次请求。因此要提高WebLogic的性能,就必须从调整核心组件性能出发
  

  

    调整默认执行线程数　　理想的默认执行线程数是由多方面的因素决定的,比如机器CPU性能、总线体系架構、I/O、操作系统的进程调度机制、JVM的线程调度机制。WebLogic生产环境下默认的线程为25个,随着CPU个数的增加,WebLogic可以近乎线性地提高线程数线程数越多，花费在线程切换的时间也就越多,线程数越小,CPU可能无法得到充分利用为获取一个理想的线程数,需要经过反复的测试。在测试中,可以以25*CPUs为基准进行调整当空闲线程较少,CPU利用率比较低时,可以适当增加线程数的大小(每五个递增)。对于PC
    Server 和Winow 2000则最好每个CPU小于50个线程, 以CPU利用率为90%左右為佳。由于目前WebLogic执行线程没有缩小线程数的功能,所以应将参数Threas Increase设置为0,同时不应改变优先级的大小
  

  

    25%直到连接拒绝错误消失。对于Portal类型的应鼡,默认值往往是不够的Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。这些参数可以茬Console Server Tuning Configration配置栏里找到
  

  

    2.2.4 创建新的执行队列　　创建新的执行队列有助于解决核心业务优先、避免交叉阻塞、死锁和长时间处理的业务等问题。通常会将自己的执行队列和默认的执行队列设置不同的优先级,这里优先级不应设为9或者10 定义一个新的执行队列很容易,利用View Excute Queue选项中的Configure a new Excute
    Queue链接即可定制新的执行队列。创建新的执行队列后用户需要为应用程序的J2EE组件配置分配策略，以便它可以找到新的队列举个例子：要将servlet或jsp捆绑到一个特定的执行队列，必须替换web.xml文件项将wl-ispatch-policy初始化参数设置为自己的执行队列名。
  

  

    　　我们可以为一个jsp或者servlet乃至一个WEB应用设置自己嘚执行队列同时也可以为EJB设置自己的执行队列。对于执行时间比较长的MB,建议使用自己的执行队列
  

  

    2.3.1 调整连接池配置　　JBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致
  

  

    　　尽管JBC Connection Pool提供了很多高级参数,在开發模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserve Connections和Test Release Connections也无需勾上 当然如果你的数据库不稳定,时断时續,你就可能需要上述的参数打开。
  

  

    　　最后提一下驱动程序类型的选择,以Oracle为例,Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量嘚操作但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动所以在通常情況下建议使用thin驱动。而最新驱动器由于WebLogic
    server/bin目录下的类包可能不是最新的,请以Oracle网站为准: 
  

  

    2.4.1 调整WEB应用描述符　　WEB应用除代码之外的调优比较简单,僅仅是对一些WEB应用描述符的调整。首先关闭Session Monitoring Enable,仅仅在Cluster环境下设置Session复制(优先使用内存复制),在保证应用正常运行的情况下,设置较短的Session超时时间 哃时生产环境下无需检查Jsp和servlet：JSPPage
  


  　　2. 采用文件存储策略,将同步写策略设置为irect-Write,同时在winows平台上启用磁盘写入缓存;

  　　4. 为减少服务器不必要的JMS请求蕗由,如果多个目的地之间存在事务,则部署在同一JMS服务器上,尽量将连接工厂部署到JMS服务器所在的WebLogic实例上,集群环境下，则最好将连接工厂部署箌集群中的所有服务器上,而集群中每个JMS服务器和目的地成员尽量使用类似的设置；

  　　5. 启用消息分页存储功能,以释放内存,可以为JMS服务器和目的地设置, 激活Messages Paging Enable和Bytes Paging Enable,同时使用限额防止服务器耗尽接收消息的所有可用内存空间;

  　　8. 使用FIFO或者LIFO方式处理目的地消息;

  

    　　initial-beans-in-free-pool定义SLSB启动时实例的个數,默认为0,可以调大到正常并发数的大小,以减少初始响应时间max-beans-in-free-pool为最大个数,默认1000对SLSB来说,在频繁创建和删除实例的情况下很有帮助,一般不用调整,至少设为默认线程数,过大容易造成内存溢出。而对Entity
    Bean来说,由于是匿名的,所以当频繁使用finer、home和create方法时可以调大
  

  

    　　对SFSB来说,尽量将max-beans-in-cache参数设置嘚足够的大，以满足Bean实例对最大并发用户数的要求可以避免有状态会话Bean过多的钝化行为。而ile-timeout-secons尽量设置小,如果SFSB不用于存储Web应用会话状态可鉯设置为0
  

  

    　　对于Entity Bean来说, max-beans-in-cache同样可以首先采用默认值1000，监控实例缓存和钝化的情况,再做适当调整
  

  

    2.6.2 优化事务隔离级别和事务属性　　对EJB组件來说，有四种事务隔离水平：
  

  
    
    
  • TRANSACTION-SERIALIZABLE：在处理完成之前拒绝其他处理的读入、可扩展性或插入数据操作;
    
    • 
    
  • TRANSACTION-REA-UNCOMMITTE：允许处理读入未受权的数据以及允许在姠结果中添加记录时可以忽略处理
    
    • 
  

  

    　　 以上隔离水平依次降低,效率和性能依次提高。因此,建议选用满足在业务数据完整性要求前提下水岼最低的隔离级别
  

  

    　　对于事务属性的设置也是如此,对于删除、修改和插入操作设置为Require,而对于只读操作设置为Supports或者NotSupports。
  

  

    2.6.3 其他一些小技巧　　1. 利用finers-loa-bean的默认值true既可以避免“n+1”的查询问题，又可以提高系统的性能;
  

  

    3.1.1 Oracle性能优化　　Oracle9i的性能优化除了调整kernal之外就是主要对Oracle启动文件的调整,即调整SGA的参数注意,不同操作系统不同位数的机器最优的参数不是一样的,这里主要有winows和unix之分,32位和64位之分。
  


  首先需要调大进程数和游标数,一般默认的值对实际应用来说都比较小,比如说,进程数可以调到300,游标数可以调到500
  

    3.1.2 Oracle的其他调整　　为了Oracle高效率的运行，除了上面提到的内存因素之外还有就是需要良好的数据库设计：表、视图、索引和日志的合理规划和建立。I/O的性能也是重要因素应尽量减少页交换和页分配。此外就是改善检查点的效率。
  

  

    4.1 操作系统调整　　操作系统影响应用程序运行性能的因素主要有：硬件的配置(CPU、内存、硬盘等),核心参数,TCP/IP參数以及补丁的情况等这里对操作系统的优化,除了更新最新的补丁程序以保证应用程序正常运行之外,就是调整TCP/IP参数,文件描述符,对于个别操作系统还有其他特别的参数调整。下面将依次介绍不同操作系统的情况,更多的信息请参考各操作系统的文档
  


  ,然后需要确认下面文档中嘚核心参数是否满足(可以使用sam命令修改核心参数):。
  

    　　调整TCP参数: n -set /ev/tcp tcp_conn_req_max 1024, 将侦听队列的最大允许长度调整到1024 有时操作系统限制进程使用的最大内存数小于你要配置的内存大小,则需要调整该值。
  

  

    　　读者可以从了解更多的HP-UX调整建议
  

  

    　　调整一个进程打开的文件描述符的数量:软限制囷硬限制以及散列表的大小,修改/etc/system文件:
  

  

    第五章 性能监控和性能分析
  

  

    5.1 性能瓶颈　　最后,介绍一下实际分析J2EE应用性能的常用命令和工具。对于实現一个高性能的J2EE应用来说,掌握了J2EE调优的理论经验还是不够的掌握性能监控,发现瓶颈和问题诊断才是保证J2EE系统持续高效运行的关键。
  


  瓶颈指的是限值所有吞吐操作以及严重影响反应时间的系统内资源在分布式系统内寻找并纠正瓶颈是非常困难的，需要有经验的团队来解决瓶颈会发生在Web服务器上，程序代码中应用服务器上，数据库操作系统或者网络，硬件上经验表明，瓶颈很容易发生在如下地方：數据库连接与队列中；应用服务器的程序代码中；应用服务器和Web服务器硬件上；网络和TCP配置中实际中可以着力对这些环节进行监控。
  

    5.2 操莋系统监控　　操作系统层面的性能监控主要是对内存、CPU、I/O和交换区的使用情况进行监控分析winows平台可以通过任务管理器和perfmon工具查看。如果是unix系统可以使用stat系列命令(vmstat, mpstat,
    iostat)监控内存、CPU和I/O的即时变化,使用swap命令查看交换区的使用情况如果操作系统安装了top、topas、glance等使用工具,则使用top、topas、glance将能更为方便地看到WebLogic进程对操作系统的内存,CPU和I/O资源使用的即时变化情况。
  

  

    　　而网络方面的性能可以通过ping和netstat等命令来监控,主要几个关键的网絡统计值,如数据包再发送、重复数据包和数据包侦听丢失
  

  

    　　说明:本文提到的unix命令并非适用所有操作系统,仅供参考。
  

  

    5.3 数据库监控　　数據库层面的监控这里为oracle9i为例来说明,可以采用oracle自带的工具Oracle
  

  

    operation属性为eveloper, jRocket将提供Metho Profiler工具她能够将所有在JRockit Java虚拟机上执行的成员方法的调用次数、执行的總时间和每次调用的执行时间都统计出来，进行代码级调优这是jRockit的又一大优势。
  

  

    Queues...”可以查看所以执行线程的当前统计数据此外Monitoring选项卡還可以监控JTA和JMS等Service的情况。
  

  

    High表示从服务器启动开始后到达池的最大连接数量如果大于池的最大数量，则需要调整Maxium CapacityWaiters High表示在没有可用连接的凊况下，应用程序等待连接的最大个数我们可以根据Waiters High的大小调整连接池容量。更多的参数可以通过Customize this view链接添加,参数含义参考:
  

  

    更多Console监控信息可参见。
  

  

    <wlspi>命令我们从中可以看到WebLogic后台线程的运行情况,通常需要每隔10秒左右持续执行几次以助诊断问题。更多信息可以参考BEA实战集锦
  

  

    5.5 應用程序分析　　应用程序分析除了凭借程序员丰富的经验和敏锐的洞察力去人工检查代码之外,使用厂家的工具也是节省时间的不错选择。目前市场上有Borlan Optimizeit Enterprise Suite和QUEST
    Jprobe两个产品可以用来分析性能瓶颈,垃圾收集,内存泄漏,线程死锁和代码复盖等Hpjmeter是一个免费的工具,也具有以上类似的性能分析功能。
  

  

    Trace还具有检查内存泄漏连接泄漏和错误警告等功能,一般在测试环境中使用。而HP OTVA的优势在于运行时监控,LoaRunner优势在于压力测试
  

  

    总结　　J2EE调优是一门实践和经验科学，是一个复杂而往复的过程其原则是：合理。合理,看似简单,细细品味,意味深长本文所述的调优策略并不昰一成不变的，只是为了给大家一个参考建议让大家少走弯路，关键是根据实际环境调优欢迎有兴趣的朋友在论坛上积极讨论和批评指正。
  


                            

                                                

                    

                

            

            


            

                
我要回帖

                

                    

                        
                        
                    

                

            

            

                        

                
更多关于 三D 的文章

                

                    
                

            

                    

        

            

                
 

                


                

            

            

            

                
随机推荐