首页 文章 精选 留言 我的

精选列表

搜索[高性能应用服务],共10008篇文章
优秀的个人博客,低调大师

NGINX Unit 1.18.0 发布,动态 Web 应用服务器

NGINX Unit 1.18.0 已发布,此版本为内部路由引入了改进用于简化部分配置,以及引入用于对应用进程进行 chroot 操作的隔离选项"rootfs"。 主要更新内容: Feature:新增"rootfs"隔离选项,用于更改应用程序的根文件系统 Feature: 在 PHP 应用中支持多 target(multiple "targets") Feature: 在"uri" 和 "arguments"匹配项和"pass"选项中支持百分比编码 简单介绍一下上面的第二个功能,此功能旨在简化许多 PHP 应用程序的配置。下面以 WordPress 为例进行说明,这是使用两种不同寻址方式的众多应用程序之一: 大部分用户的请求都是由 index.php 处理,无论实际的请求 URI 如何 事务管理接口和一些组件依赖于直接请求到 URI 中命名的特定 .php 脚本 在旧版本中,用户必须配置两个 Unit 应用程序来处理这种差异: { "wp_index": { "type": "php", "user": "wp_user", "group": "wp_user", "root": "/path/to/wordpress/", "script": "index.php" }, "wp_direct": { "type": "php", "user": "wp_user", "group": "wp_user", "root": "/path/to/wordpress/" } } 第一个应用程序直接执行 URI 命名的 .php 脚本,而第二个应用程序将所有请求传递给 index.php。 现在可以使用"targets"进行替代: { "wp": { "type": "php", "user": "wp_user", "group": "wp_user", "targets": { "index": { "root": "/path/to/wordpress/", "script": "index.php" }, "direct": { "root": "/path/to/wordpress/" } } } } 详细内容查看发布说明。 NGINX Unit 是用于各种 Web 应用程序的轻量动态开源服务器。NGINX Unit 从头开始构建,可以一次运行多种语言版本的 Web 应用程序,它也可以在运行时完全配置为零中断,从而可以对工程和操作进行实时粒度管理。

优秀的个人博客,低调大师

NGINX Unit 1.16.0 发布,动态 Web 应用服务器

NGINX Unit 1.16.0 已发布,此版本新增两个功能:fallback路由和通过配置upstreams 实现的轮询调度(Round-Robin)负载均衡。熟悉 nginx 的开发者对这两个功能应该不会陌生。 fallback路由(fallback Routing Option):当静态文件由于某种原因不能被送达时,可以定义一个替代路由 action。 通过配置upstreams 实现的轮询调度负载均衡:upstreams 对象所驻留的配置部分可作为监听器、应用程序、路由和设置对象的对等者。upstream 是将多个服务器分组到一个单一逻辑实体中的抽象,以简化管理和监控。通常情况下,可在 upstream 中分发工作负载、指派不同角色,并对单个服务器的属性进行微调,但从外部看,它看起来和相关表现就像一个单一实体。 在 NGINXUnit 中,upstreams 被配置成如下: { "listeners": { "*:80": { "pass": "upstreams/rr-lb" } }, "upstreams": { "rr-lb": { "servers": { "192.168.0.100:8080": { }, "192.168.0.101:8080": { "weight": 2 } } } } } 详细更新内容查看发布公告 https://www.nginx.com/blog/nginx-unit-1-16-0-now-available/

优秀的个人博客,低调大师

NGINX Unit 1.15.0 发布,动态 Web 应用服务器

NGINX Unit 1.15.0 已发布,NGINX Unit 是用于各种 Web 应用程序的轻量动态开源服务器,它从头开始构建,可以一次运行多种语言版本的 Web 应用程序。它也可以在运行时完全配置为零中断,从而可以对工程和操作进行实时粒度管理。 此版本主要是一个修复错误的版本,另外,它还解决了因最近发布的主要 Ruby 版本中的较小 API 更改而导致的不兼容性。 更新内容如下: Change:动态请求PHP 脚本的扩展名限制为".php" Feature:兼容 Ruby 2.7 Bugfix:路由器进程中可能存在段错误,具体现象是负载下有多个应用程序进程;该错误已在 1.14.0 中出现 Bugfix:修复通过 TLS 连接接收请求正文可能出现停止的问题 最后,开发团队表示计划在下一个版本(预计三月初发布)中提供更多功能,其中包括代理模块中的基本负载平衡 和用于更复杂的请求路由的"try_files"之类的功能。 要了解更多近期推出的一些功能,请查看官方博客。

优秀的个人博客,低调大师

NGINX Unit 1.14.0 发布,动态 Web 应用服务器

NGINX Unit 1.14.0 已发布,NGINX Unit 是用于各种 Web 应用程序的轻量动态开源服务器,它从头开始构建,可以一次运行多种语言版本的 Web 应用程序。它也可以在运行时完全配置为零中断,从而可以对工程和操作进行实时粒度管理。 此版本更新内容如下: Change:Go 软件包导入名称更改为 "unit.nginx.org/go". Change: Go 软件包现在链接到 libunit,而不是库资源 Feature: 当 Unit 守护程序以非特权用户身份运行时,能够更改隔离应用程序的用户和组 Feature: 支持按源和目标地址以及端口请求路由 Bugfix: 修复在大型的响应下出现内存泄露的情况 要了解更多近期推出的一些功能,请查看官方博客。

优秀的个人博客,低调大师

Nginx Unit 1.12.0 发布,动态 Web 应用服务器

Nginx Unit 1.12.0 已发布,此版本包含几个重要的错误修正。官方表示这是一个临时版本,着重于修复一些烦人的错误,并增加了与即将于2019年11月28日发布的 PHP 7.4 的兼容性 。 1.12.0 主要更新内容: 新特性:兼容 PHP 7.4 Bugfix:创建进程时出现描述符(descriptors)泄露的情况;此 bug 最早在 1.11.0 中出现 Bugfix:发送响应时,TLS 连接可能过早关闭 Bugfix:如果请求了不规则文件(irregular file),可能会发生段错误 如需了解 Nginx Unit 的未来计划,请点此查看。要了解更多近期推出的一些功能,请查看官方博客。 此外,团队已更新Docker 镜像,增加了一个初始化脚本显著简化容器内 Nginx Unit 守护进程的初始配置。详情请查看文档中的说明。

优秀的个人博客,低调大师

如何将传统应用服务“直接迁移”至容器环境

已经准备好向容器迁移了吗?如果你正考虑从现有非容器化的系统上将服务迁移到基于容器的环境中,那么你一定想知道该如何实现它。有什么正确的方法?有没有最好的方法?或者说,有没有某种直接迁移过程(lift-and-shift process)可以适用于所有的应用程序? 通常来讲,上述问题都有肯定的答案。虽然因各公司的具体情况不同,迁移到容器和微服务的具体细节会各有差异,但是对于实现应用程序从传统基础设施到容器环境的无缝迁移来说,还是有一些普适性原则和最佳实践经验值得大家遵循。 这篇博文将简要介绍成功将传统应用程序迁移到容器的指导原则。 微服务——它们是什么? 在处于项目迁移的最初规划阶段,关于容器化,最需要注意的是容器系统架构是基于(或应该基于)微服务的。那么,微服务是什么? 实际上,界定什么是微服务、什么不是微服务,这其间的标准是有些模糊的。这种情况其实是一种必然,因为不同的设计容器化应用程序的方法(我们稍后会提到),正是基于不同的定义微服务的方法。 从总体上来说,微服务可以描述为一个基本的、功能分离的服务,它由应用程序的其他部分调用。我们可以把从数据库中检索数据的服务看作是一个微服务,既可以将数据发送到存储设备,也可以处理用户输入。 例如,在线上商店中,访问库存数据库是由一个微服务处理,客户的购物车由一个微服务更新,交易再由一个微服务完成,并且还有一个微服务处理信用卡的授权,而这些微服务都是独立的。 而对于同一家店,可以由多个微服务工作,一个微服务处理所有的数据库访问(库存、客户和销售),一个微服务处理购物车和交易,而第三个微服务用做运输物流。这种特定的微服务结构,在很大程度上是一种设计选择,它取决于系统整体架构。 你当前的架构是什么? 不过,在开始构建容器化应用程序之前,还需要着留意一下你当前的架构。宏观上,非容器化的应用程序可以大体分为两类:单体架构和SOA架构(服务导向架构)。当前架构不同,进行容器化重构的方法就不同,因此我们先将它们区分开来,再讨论设计选择以及整体的重构策略。 单体架构 大多数传统设计的应用程序都是单体架构。它们可能由单个包含了支持的库、服务以及配置文件的程序,或者少量带支持资源的程序组成。然而,在这两种情况下,大部分甚至全部的核心功能都包含在一个或几个二进制文件中,其中服务就包含于这些在二进制文件定义的应用程序边界内进行操作和通信的功能中。桌面级的应用程序传统上讲是单体的,大多数基于网络的应用程序也是如此。 在桌面或局域网环境中,单体架构通常是十分有效的。它的安装和更新相当容易,并且单体的设计能够轻松地监控组件,而且桌面/LAN的使用一般不会对应用程序的资源造成太大的压力。然而,在云或互联网的环境中,单体应用程序可能相对过于庞大、笨拙、缓慢,它们不仅难以更新,且不能够处理大量的流量。另外,它们也不适用持续交付以及大多数构成DevOps的实践。 如果想重构容器的单体架构应用,那可能需要在概念层面上进行全盘的重新设计。即便应用程序的架构已经相当清晰地定义了其内部服务,并且保证了它的离散性,实际拆分成微服务时可能还需要对这些服务的边界以及它们彼此通信的方式进行大规模的更改。对于大多数的单体应用程序,许多服务都需要重新定义,甚至需要从头开始定义。 SOA架构 有一些大型的非容器应用程序可能已经具有了基于服务的架构。例如,销售点的应用程序可能包含了独立的程序用来处理销售、库存、客户记录、订单、运输、差异、税收、应收账款以及应付账款。每一个模块都是一个单独的程序,具有明确的应用程序边界,而且这种跨边界的模块间通信和基于容器的应用程序十分相似。 如果有进行细分的需要,这种架构(假设它是令人满意的)可以作为进一步分解成微服务的基础。进一步分解可以是基于现有的模块分解成更小的服务,也可以是基于抽象的广义服务(比如访问单个数据库或打印收据的微服务),或者两者都是。另一方面,如果现有模块已经是小容量、功能分散且组织良好的,那么只需要进行极少的修改就可以将其迁移到容器中。 对于单体应用你要怎么做? 在这一点上,应该弄清楚的是,将单体应用程序分解成微服务通常是一个复杂而极具挑战的工作。就像之前说的那样,首先是根据微服务重新定义架构。这里的重新定义以及实际细分成微服务本身的过程通常称为分解(decomposition)。关于分解有一些基本的模式。在很多情况下,了解这些模式的基础和基本性质比选择哪种模式更重要,而在实际生产中,根据系统的功能要求,将单体应用程序分解成微服务时常常涉及到多种模式。 根据用例分解 用例是指用户在执行任务时通常会采取的一组操作。用户既可以是实际的人,可以是应用程序的另一部分,也可以是外部的应用程序。用例的关键要素是它是与任务相关联的一组可定义的动作。在线上商店的例子中,一组客户操作(如选择和购买商品)就可以是一个用例,单纯的内部操作也可以是用例,例如在销售之后更新库存、客户信息以及交易数据库。 根据功能分解 根据功能分解是分解的另一种常见模式。例如,销售交易可以是一个由功能定义的单元,而信用授权可以作为由功能定义的另一个服务。你可以根据诸如差异跟踪、运输和自动补货这些功能来定义功能域。功能分解和用例分解非常相似,不过它的定义更多的是由需要执行的行为决定而非执行的对象。 根据资源分解 在多数情况下,根据资源定义特定的微服务无疑是最好的方案。例如,你可以定义一个单一的微服务来处理所有与具体某个数据库或一组数据库的交互,或者处理所有与持久存储器的交互。在许多方面,设备驱动程序是基于资源的微服务。如果通过某种类似于设备驱动程序的通用服务来和资源进行交互是有意义的,那么将该服务定义为微服务也可能有实际价值。 分解途径 确定了分解单体应用的整体模式后,就可以开始将其分解成微服务。你的最终目标应该是将整个应用程序缩成一组微服务层级的容器,它们和原始的单体应用一样,提供相同的一组服务(能够根据需要添加或改进功能),可以根据需要进行管理和部署,而且相比之下有更出色的速度、流量以及灵活性。 比较好的一点是,你并不需要一下子把它拆散。可以将前面说的大型SOA架构作为中间阶段。你可以在开始的时候将单体应用程序拆成大型的基于服务的块,然后再将其细分成越来越小的服务,直到最终达到期望目标级别的微服务。而这里还有另一种方案,你可以从定义明确的服务入手,先将这些服务拆分成基于容器的微服务,然后再以类似先前的方法,分几次拆分应用程序的其余部分。 无论采取哪种方法,一定要牢记一点,那就是要明确定义微服务,而且这些定义在应用程序的整体功能和架构上都应该是有实际意义的。只要你遵循了这些原则,相信你的迁移工作就会成功。 原文来源:Rancher Labs 本文转自 RancherLabs 51CTO博客,原文链接:http://blog.51cto.com/12462495/1976657

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册