Category Archives: Programming Language

在 Windows 服务中托管 ASP.NET Core

不将 IIS 用作 Windows 服务时，可在 Windows 上托管 ASP.NET Core 应用。 作为 Windows 服务托管时，无需人工干预应用即可在重新启动和崩溃后自动启动。 查看或下载示例代码（如何下载） 将项目转换为 Windows 服务 要将现有 ASP.NET Core 项目设置为作为服务运行，至少需要执行以下更改： 在项目文件中： 确认是否存在 Windows 运行时标识符 (RID)，或将其添加到包含目标框架的 <PropertyGroup> 中： XML复制

要发布多个 RID： 通过以分号分隔的列表提供 RID。 使用属性名称 <RuntimeIdentifiers>（复数）。 有关详细信息，请参阅 .NET Core RID 目录。 为 Microsoft.AspNetCore.Hosting.WindowsServices 添加包引用。 在 Program.Main 中，进行下列更改： 调用 host.RunAsService，而不是 host.Run。 调用 UseContentRoot 并使用应用的发布位置路径，而不是 Directory.GetCurrentDirectory()。 C#复制

发布应用。 使用 dotnet publish 或 Visual Studio 发布配置文件。 使用 Visual Studio 时，请选择 FolderProfile。 要使用命令行接口 (CLI) 工具发布示例应用，请在项目文件夹的命令提示符处运行 dotnet publish 命令。 必须在项目文件的 <RuntimeIdenfifier>（或 <RuntimeIdentifiers>）属性中指定 RID。 在以下示例中，应用在 win7-x64 运行时的发布配置中发布： console复制

使用 sc.exe 命令行工具创建服务。 binPath 值是应用的可执行文件的路径，其中包括可执行文件的文件名。 等于号和路径开头的引号字符之间需要添加空格。 console复制

对于项目文件夹中发布的服务，请使用 publish 文件夹的路径创建服务。 如下示例中： 该项目位于 c:\my_services\AspNetCoreService 文件夹中。 项目在 Release 配置中发布。 目标框架名字对象 (TFM) 为 netcoreapp2.1。 运行时标识符 (RID) 为 win7-x64。 应用可执行文件名为 AspNetCoreService.exe。 服务名为 MyService。 示例: console复制

重要 确保 binPath= 参数与其值之间存在空格。 从其他文件夹发布和启动服务： 使用 dotnet publish 命令上的 --output <OUTPUT_DIRECTORY> 选项。 如果使用 Visual Studio，请在“FolderProfile”发布属性页面中配置“目标位置”，然后再选择“发布”按钮。 通过使用输出文件夹路径的 sc.exe 命令创建服务。 在向 binPath 提供的路径中包含服务可执行文件的名称。 使用 sc […]

View Details

解决:Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.2:compile

在项目构建的时候遇到了这样的问题:Failedto execute goal org.apache.maven.plugins:maven-compiler-plugin:3.2:compile(default-compile) on project taotao-manager-pojo: Compilation failure 检查了一下Installed JREs的设置,使用的环境变量为jre 解决方法: 将Installed JREs的设置修改为jdk即可.这里选择的其实是JAVA_HOME路径，jdk中包含jre 即可正常运行. ——————— 作者：陈晓婵 来源：CSDN 原文：https://blog.csdn.net/chenxiaochan/article/details/62036671 版权声明：本文为博主原创文章，转载请附上博文链接！

View Details

eclipse中，将springboot项目打成jar包

1.右击项目，选择Run As – Maven clean 2.右击项目，选择Run As – Maven install 3.成功后 会在项目的target文件夹下生成jar包 4.将打包好的jar包 发布到服务器，运行java -jar jar包 5.或者使用命令nohup java -jar jar包，nohup命令可以后台启动jar,如果 直接运行 java -jar 则关闭终端，spring的进程也会关闭。 ——————— 作者：浅月流苏 来源：CSDN 原文：https://blog.csdn.net/wsf408908184/article/details/80760679 版权声明：本文为博主原创文章，转载请附上博文链接！

View Details

为 .NET Core 应用程序生成 Docker 映像

本教程重点介绍了如何在 Docker 上使用 .NET Core。 首先，我们探讨 Microsoft 维护和提供的各种不同的 Docker 映像，及其使用情况。 然后讲解了如何生成和 Docker 化 ASP.NET Core 应用。 在本教程中可学习： 了解 Microsoft.NET 核心 Docker 映像 获取用于 dockerize 的 ASP.NET Core 示例应用程序 在本地运行 ASP.NET 示例应用 使用 Docker for Linux 容器生成和运行示例 使用 Docker for Windows 容器生成和运行示例 Docker 映像优化 为开发人员生成 Docker 映像时，侧重于以下三种主要方案： 用于开发 .NET Core 应用的映像 用于生成 .NET Core 应用的映像 用于运行 .NET Core 应用的映像 为什么是三个映像？ 因为在开发、生成和运行容器化应用程序时，具有不同的优先级。 开发： 优先级注重循环访问更改的速度以及调试更改的能力。 与更改代码并且快速查看相比，映像的大小是否不是那么重要？ 生成： 此映像包含编译应用所需的所有内容，其中包括编译器和任何其他用于优化二进制文件的依赖项。 可使用生成映像创建置于生产映像中的资产。 生成映像用于持续集成或用于生成环境中。 此方法允许生成代理在生成映像实例中编译和生成应用程序（包括所有必需的依赖项）。 生成代理只需要了解如何运行此 Docker 映像即可。 生产： 部署和启动映像的速度可以有多快？ 此映像很小，因此从 Docker 注册表到 Docker 主机的网络性能得到了优化。 已准备运行内容，以此实现从 Docker 运行到处理结果的最快时间。 Docker 模型中不需要动态代码编译。 放置在此映像中的内容将限制为运行应用程序所需的二进制文件和内容。 例如，dotnet publish 输出包含： 已编译的二进制文件 .js 和 .css 文件 在生产映像中包括 dotnet publish 命令输出的原因是使生产映像保持最小大小。 某些 .NET Core 映像共享不同标记之间的层，因此下载最新标记是一个相对轻量的过程。 如果计算机上已有较早版本，此体系结构会降低所需的磁盘空间。 当多个应用程序在同一计算机上使用公共映像时，在公共映像之间共享内存。 映像必须相同才可共享。 Docker 映像变体 为了实现上述目标，我们在 microsoft/dotnet 下提供了映像变体。 microsoft/dotnet:<version>-sdk(microsoft/dotnet:2.1-sdk) 此映像包含带有 […]

View Details

Docker 容器、映像和注册表

使用 Docker 时，开发人员会创建一个应用或服务，并将它及其依赖项打包到一个容器映像中。 映像是应用或服务及其配置和依赖项的静态表示形式。 若要运行应用或服务，应用的映像会实例化，以创建一个在 Docker 主机上运行的容器。 最初，会在开发环境或 PC 中测试容器。 开发人员应将映像存储在注册表中，该注册表可充当映射库并在部署到生产业务流程协调程序时使用。 Docker 通过 Docker 中心维护公共注册表；其他供应商为不同映像集合提供注册表，包括 Azure 容器注册表。 或者，企业可以拥有一个本地专用注册表，用于其 Docker 映像。 图 2-4 显示了 Docker 中的映像和注册表与其他组件相关联的方式。 还显示了供应商的多个注册表产品/服务。 图 2-4。 Docker 术语和概念的分类 将映射存储到注册表中可存储静态和不可变的应用程序，包括其在框架级别的所有依赖项。 然后，这些映像可部署到多种环境中，并进行版本控制，从而提供一致的部署单元。 无论是托管在本地还是托管在云中，在下列情况下都建议使用专用映像注册表： 由于保密性，不能公开分享映像。 在映像和所选部署环境之间，希望网络延迟保持最低。 例如，如果生产环境是 Azure 云，为实现最低的网络延迟，可将映像存储在 Azure 容器注册表中。 同样，如果生产环境是在本地，便需要使本地 Docker 信任的注册表在相同的本地网络中可用。 from:https://docs.microsoft.com/zh-cn/dotnet/standard/microservices-architecture/container-docker-introduction/docker-containers-images-registries

View Details

Docker 术语

本节列出了在深入了解 Docker 之前应熟悉的术语和定义。 有关进一步的定义，请参阅 Docker 提供的详细术语表。 容器映像：包含创建容器所需的所有依赖项和信息的包。 映像包括所有依赖项（例如框架），以及容器运行时使用的部署和执行配置。 通常情况下，映像派生自多个基础映像，这些基础映像是堆叠在一起形成容器文件系统的层。 创建后，映像不可变。 Dockerfile：包含有关如何生成 Docker 映像的说明的文本文件。 与批处理脚本相似，首先第一行将介绍基础映像，然后是关于安装所需程序、复制文件等操作的说明，直至获取所需的工作环境。 生成：基于其 Dockerfile 提供的信息和上下文生成容器映像的操作，以及生成映像的文件夹中的其他文件。 可以使用 Docker 的“docker 生成”命令生成映像。 容器：Docker 映像的实例。 容器表示单个应用程序、进程或服务的执行。 它由 Docker 映像的内容、执行环境和一组标准指令组成。在缩放服务时，可以从相同的映像创建多个容器实例。 或者，批处理作业可以从同一个映像创建多个容器，向每个实例传递不同的参数。 卷：提供一个容器可以使用的可写文件系统。 由于映像只可读取，而多数程序需要写入到文件系统，因此卷在容器映像顶部添加了一个可写层，这样程序就可以访问可写文件系统。 程序并不知道它正在访问的是分层文件系统，此文件系统就是往常的文件系统。 卷位于主机系统中，由 Docker 管理。 标记：可以应用于映像的标记或标签，以便可以识别同一映像的不同映像或版本（具体取决于版本号或目标环境）。 多阶段生成：Docker 17.05 或更高版本的一个功能，可帮助减小最终映像的大小。 概括来说，借助多阶段生成，可以使用一个包含 SDK 的大型基础映像（以此为例）编译和发布应用程序，然后使用发布文件夹和一个小型仅运行时基础映像生成一个更小的最终映像 存储库 (repo)：相关的 Docker 映像集合，带有指示映像版本的标记。 某些存储库包含特定映像的多个变量，例如包含 SDK（较重）的映像，包含唯一运行时（较轻）的映像，等等。这些变量可以使用标记进行标记。 单个存储库中可包含平台变量，如 Linux 映像和 Windows 映像。 注册表：提供存储库访问权限的服务。 大多数公共映像的默认注册表是 Docker 中心（归作为组织的 Docker 所有）。 注册表通常包含来自多个团队的存储库。 公司通常使用私有注册表来存储和管理其创建的映像。 另一个示例是 Azure 容器注册表。 多体系结构映像：就多体系结构而言，它是一种根据运行 Docker 的平台简化相应映像选择的功能，例如当 Dockerfile 从注册表请求基础映像 FROM microsoft/dotnet:2.1-sdk 时，实际上它会获得 2.1-sdk-nanoserver-1709、2.1-sdk-nanoserver-1803 或 2.1-sdk-alpine，具体取决于操作系统和运行 Docker 的版本。 Docker Hub：上传并使用映像的公共注册表。 Docker 中心提供 Docker 映像托管、公共或私有注册表，生成触发器和 Web 挂钩，以及与 GitHub 和 Bitbucket 集成。 Azure 容器注册表：用于在 Azure 中使用 Docker 映像及其组件的公共资源。 这提供了接近 Azure 中部署的注册表，授予控制访问权限，使其可以使用 Azure Active Directory 组和权限。 Docker 受信任注册表 (DTR)：Docker 注册表服务（来自 Docker），可以安装在本地，因此它存在于组织的数据中心和网络中。 这对于应该在企业内部管理的私有映像来说很方便。 Docker 受信任注册表是 Docker 数据中心产品的一部分。 有关详细信息，请参阅 Docker 受信任注册表 […]

View Details

什么是 Docker？

Docker 是一种开源项目，用于将应用程序自动部署为可在云或本地运行的便携式独立容器。 Docker 也是一家公司，它与云、Linux 和 Windows 供应商（包括 Microsoft）协作，致力于推广和发展这项技术。 图 2-2。 Docker 在混合云的所有层部署容器 Docker 映像容器可以在 Linux 和 Windows 上本机运行。 但是，Windows 映像仅能在 Windows 主机上运行，Linux 映像可以在 Linux 主机和 Windows 主机上运行（到目前为止，使用 Hyper-V Linux VM），其中主机是指服务器或 VM。 开发人员可以在 Windows、Linux 或 macOS 上使用开发环境。 在开发计算机上，开发人员运行部署了 Docker 映像（包括应用及其依赖项）的 Docker 主机。 在 Linux 或 Mac 上进行开发的开发人员使用基于 Linux 的 Docker 主机，并且他们可以仅为 Linux 容器创建映像。 （在 Mac 上进行开发的开发人员可以从 macOS 中编辑代码或运行 Docker CLI，但截至撰写本文时，容器不在 macOS 上直接运行。）在 Windows 上进行开发的开发人员可以为 Linux 或 Windows 容器创建映像。 为了在开发环境中承载容器，并提供其他开发人员工具，Docker 为 Windows 或 macOS 提供了 Docker 社区版 (CE)。 这些产品安装了承载容器所需的 VM（Docker 主机）。 Docker 还提供 Docker 企业版 (EE)，该版本专为企业开发而设计，供生成、交付和在生产中运行大型业务关键型应用程序的 IT 团队使用。 若要运行 Windows 容器，有两种类型的运行时可供使用： Windows Server 容器通过进程和命名空间隔离技术提供应用程序隔离。 Windows Server 容器与容器主机和主机上运行的所有容器共享内核。 Hyper-V 容器通过在高度优化的虚拟机中运行各容器来扩展 Windows Server 容器提供的隔离。 在此配置中，容器主机的内核不与 Hyper-V […]

View Details

容器和 Docker 简介

容器化是软件开发的一种方法，通过该方法可将应用程序或服务、其依赖项及其配置（抽象化为部署清单文件）一起打包为容器映像。 容器化应用程序可以作为一个单元进行测试，并可以作为容器映像实例部署到主机操作系统 (OS)。 就像船只、火车或卡车运输集装箱而不论其内部的货物一样，软件容器充当软件部署的标准单元，其中可以包含不同的代码和依赖项。 按照这种方式容器化软件，开发人员和 IT 专业人员只需进行极少修改或不修改，即可将其部署到不同的环境。 容器还会在共享 OS 上将应用程序彼此隔离开。 容器化应用程序在容器主机上运行，而容器主机在 OS（Linux 或 Windows）上运行。因此，容器的占用比虚拟机 (VM) 映像小得多。 每个容器可以运行整个 Web 应用或服务，如图 2-1 所示。 在此示例中，Docker 主机是容器主机，而 App1、App2、Svc 1 和 Svc 2 是容器化应用程序或服务。 图 2-1. 在一个容器主机上运行多个容器 容器化的另一个优势在于可伸缩性。 通过为短期任务创建新容器，可以快速扩大。 从应用程序的角度来看，实例化映像（创建容器）类似于实例化 服务或 Web 应用等进程。 但出于可靠性考虑，在多个主机服务器上运行同一映像的多个实例时，通常要使每个容器（映像实例）在不同容错域中的不同主机服务器或 VM 中运行。 总而言之，容器在整个应用程序生命周期工作流中提供以下优点：隔离性、可移植性、灵活性、可伸缩性和可控性。 最重要的优点是可在开发和运营之间提供隔离。 from:https://docs.microsoft.com/zh-cn/dotnet/standard/microservices-architecture/container-docker-introduction/index

View Details

静态资源缓存控制编译工具

前不久在 知乎 上回答了一个问题：大公司里怎样开发和部署前端代码？。其中讲到了大公司在前端静态资源部署上的一些要求： 配置超长时间的本地缓存 —— 节省带宽，提高性能 采用内容摘要作为缓存更新依据 —— 精确的缓存控制 静态资源CDN部署 —— 优化网络请求 更资源发布路径实现非覆盖式发布 —— 平滑升级 其中比较复杂的部分就是 以文件的摘要信息为依据，控制缓存更新与非覆盖式发布 这个细节。因此基于 fis 包装了一个简单的命令行工具，并设立此项目，用于演示这部分功能。 这个工具基于 fis 的小工具是完全可以用作工程中的，有任何问题可以在 这里 留言。 请跟着下面的步骤来使用这个命令行小工具： 第一步：安装工具 这个命令行小工具依赖 nodejs 环境，因此，请先确保本地安装了它。 使用 nodejs 随带的 npm 包管理工具进行安装：

第二步：创建项目 在 命令行 下clone本仓库，或者自己创建一个新的项目，并进入：

在项目根目录下创建一个空的 fis-conf.js 文件，这是工具配置，什么都不用写，空着就行。 然后开始在项目目录下，随意创建或添加 页面、脚本、样式、图片、字体、音频、视频等等前端资源文件，正常写前端代码吧！ 第三步：发布代码 在项目根目录下执行：

然后去到 ../output 目录下去查看一下产出结果吧，所有静态资源都以md5摘要形式发布了出来，所有资源链接，我说 所有链接，包括html中的图片、样式、脚本以及js中的资源地址、css中的资源地址全部都加上了md5戳。 上述命令中，--md5 就是表示要给所有资源定位标记加上摘要信息的意思，不加这个参数就没有摘要信息处理。--dest ../output 表示把代码发布到当前目录上一级的output目录中。整个这条命令还可以简写成：

或者进一步连写成：

在本地服务器中浏览发布代码 你本地安装了诸如 Apache、Nginx、Lighttpd、IIS等服务器么？如果安装了，假设你的服务器 根目录 在 d:\wwwroot，你可以利用rsd工具的release命令，把代码发布过去，比如：

这样就把代码发布到了本地服务器根目录下，然后就可以在浏览器中查看效果了！ 如果你本地没有安装任何服务器，你可以使用rsd内置的调试服务器，执行命令：

接下来我们同样要把代码发布到这个内置服务器中，release命令如果省略 --dest <path>参数，就表示把代码发布到内置服务器的根目录下：

在浏览器中访问： http://localhost:8080 即可   一些小技巧 rsd集成了对很多前端编程语言的支持，包括： 类CSS语言：less, sass, scss, stylus 类JS语言：coffee-script 类HTML语言：markdown, jade 前端模板：handlebars-v1.3.0, EJS 内置了压缩器，在release的时候追加 -o 或者 --optimize 参数即可开启，压缩器包括： clean-css: 压缩所有类CSS语言代码 uglify-js: 压缩所有类JS语言代码 html-minifier: 压缩所有类HTML语言代码 还可以给资源加CDN域名，在release的时候追加 -D 或者 --domains 参数即可，域名配置写在fis-conf.js里：

所有常规代码中的资源定位接口都会经过工具处理，包括： 类CSS文件中： 背景图url font-face字体url ie特有的滤镜属性中的src 类JS文件中： 提供了一个叫 __uri('path/to/file') 的编译函数用于定位资源 类HTML文件中： link标签的href属性 script, img, video, audio, object 等标签的src属性 script标签中js代码里的资源定位标记 style标签中css代码里的资源定位标记 所有资源文件可以任意相互引用，工具会处理资源定位标记，使之服从知乎回答中提到的优化策略。 还提供了资源内嵌的编译接口，用于把一个资源的内容以文本、字符串或者base64的形式嵌入到 任意 一个文本文件中。 为了不用每次保存代码就执行一下release命令，工具中提供了文件监听和浏览器自动刷新功能，只要在release的时候在追加上 -w 和 -L 两个参数即可（注意L的大小写），比如：

关于这个小工具 它的原码在 这里。是的，就这么一点点代码，花了大概半小时写完的，因为一切都在 fis 中集成好了，我只是追加几个语言编译插件而已。   from:https://github.com/fouber/static-resource-digest-project

View Details

C#中HttpClient使用注意：预热与长连接

原文地址:C#中HttpClient使用注意：预热与长连接 最近在测试一个第三方API，准备集成在我们的网站应用中。API的调用使用的是.NET中的HttpClient，由于这个API会在关键业务中用到，对调用API的整体响应速度有严格要求，所以对HttpClient有了格外的关注。 开始测试的时候，只在客户端通过HttpClient用PostAsync发了一个http post请求。测试时发现，从创建HttpClient实例，到发出请求，到读取到服务器的响应数据总耗时在2s左右，而且多次测试都是这样。2s的响应速度当然是无法让人接受的，我们希望至少控制在100ms以内。于是开始追查这个问题的原因。 在API的返回数据中包含了该请求在服务端执行的耗时，这个耗时都在20ms以内，问题与服务端API无关。于是把怀疑点放到了网络延迟上，但ping服务器的响应时间都在10ms左右，网络延迟的可能性也不大。 当我们正准备换一个网络环境进行测试时，突然想到，我们的测试方式有些问题。我们只通过HttpClient发了一个PostAsync请求，假如HttpClient在第一次调用时存在某种预热机制（比如在EF中就有这样的机制），现在2s的总耗时可能大多消耗在HttpClient的预热上。 于是修改测试代码，将调用由1次改为100次，然后恍然大悟地发现——只有第1次是2s，接下来的99次都在100ms以内。果然是HttpClient的某种预热机制在搞鬼！ 既然知道了是HttpClient预热机制的原因，那我们可以帮HttpClient进行热身，减少第一次请求的耗时。我们尝试了一种预热方式，在正式发http post请求之前，先发一个http head请求，代码如下：

经测试，通过这种热身方法，可以将第一次请求的耗时由2s左右降到1s以内（测试结果是700多ms）。 在知道第1次HttpClient请求耗时2s的真相之后，我们将目光转向了剩下的99次耗时100ms以内的请求，发现绝大部分请求都在50ms以上。有没有可能将之降至50ms以下？而且，之前一直有这样的纠结：每次调用是不是一定要对HttpClient进行Dispose()？是不是要将HttpClient单例或者静态化（声明为静态变量）？借此机会一起研究一下。 在HttpClient的背后，有一个对请求响应速度有着不容忽视影响的东东——TCP连接。一个HttpClient实例会关联一个TCP连接，在对HttpClient进行Dispose时，会关闭TCP连接（我们用Wireshark进行网络抓包也验证了这一点）。 在之前的测试中，我们每次用HttpClient发请求时，都是新建一个HttpClient实例，用完就对它进行Dispose，代码如下：

所以每次请求时都要经历新建TCP连接->传数据->关闭连接（也就是通常所说的短连接），而且雪上加霜的是请求用的是https，建立TCP连接时还需要一个基于公私钥加解密的key exchange过程：Client Hello -> Server Hello -> Certificate -> Client Key Exchange -> New Session Ticket。 如果我们想将请求响应时间降至50ms以下，就必须从这个地方下手——重用TCP连接（也就是通常所说的长连接）。要实现长连接，首先需要的就是在HttpClient第1次请求后不关闭TCP连接（不调用Dispose方法）；而要让后续的请求继续使用这个未关闭的TCP连接，我们必须要使用同一个HttpClient实例；而要使用同一个HttpClient实例，就得实现HttpClient的单例或者静态化。之前的3 个问题，由于要解决第1个问题，后2个问题变成了别无选择。 为了实现长连接，我们将HttpClient的调用代码改为如下的样子：

然后测试一下请求响应时间：

除了第1次请求，接下来的99次请求绝大多数都在50ms以内。TCP长连接的效果必须的！ 通过Wireshak抓包也验证了长连接的效果： 这时，你也许会产生这样的疑问：将HttpClient声明为静态变量，会不会存在线程安全问题？我们当时也有这样的疑问，后来在stackoverflow上找到了答案：

HttpClient的所有异步方法都是线程安全的，放心使用。 到这里，HttpClient的问题是不是可以完美收官了？。。。稍等，还有一个问题。 客户端虽然保持着TCP连接，但TCP连接是两口子的事，服务器端呢？你不告诉服务器，服务器怎么知道你要一直保持TCP连接呢？对于客户端，保持TCP连接的开销不大；但是对于服务器，则完全不一样的，如果默认都保持TCP连接，那可是要保持成千上万客户端的连接啊。所以，一般的Web服务器都会根据客户端的诉求来决定是否保持TCP连接，这就是keep-alive存在的理由。 所以，我们还要给HttpClient增加一个Connection:keep-alive的请求头，代码如下：

现在终于可以收官了。但是肯定不完美，分享的只是解决问题的过程。   from:https://www.cnblogs.com/JustYong/p/5872296.html

View Details