一切福田,不離方寸,從心而覓,感無不通。

Category Archives: Backend

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

龙生   22 Oct 2018
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 受信任注册表 […]

龙生   22 Oct 2018
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 […]

龙生   22 Oct 2018
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

龙生   22 Oct 2018
View Details

使用nginx-http-concat优化网站响应

前言: 我们在访问淘宝的时候,会看到代码中的js和css文件是通过一次请求或得的,我们知道浏览器一次请求只能并发访问数个资源,这样的处理错输在网络传输层面可以大大节省时间,这里使用的技术就是把css、js等静态资源合并为一个资源。淘宝使用的tengine是基于nginx的web服务器,从11年底开源。所使用的是mod_concat模块,合并多个文件在一个响应报文中。 http1.1下浏览器的并发访问资源数 IE6                                 2 IE7                                 2 IE8                                 6 Firefox2                          2 Firefox3                          6 Safari 3,4         […]

龙生   20 Oct 2018
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

龙生   19 Oct 2018
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

龙生   07 Oct 2018
View Details

Github 修正上传时“this exceeds GitHub’s file size limit of 100 MB”错误

Github只允许上传最大100MB的文件,如果超过,则会被server reject 则需: git filter-branch --force --index-filter "git rm --cached --ignore-unmatch FILEPATH"  --prune-empty --tag-name-filter VERSION — --all git commit --amend -CHEAD git push origin master 注意要在.git文件夹目录下执行以上命令 http://www.walbrix.com/jp/blog/2013-10-github-large-files.html from:https://blog.csdn.net/fightforyourdream/article/details/25357121

龙生   07 Oct 2018
View Details

C# HttpClient请求

  from:https://www.cnblogs.com/louby/p/8021527.html

龙生   07 Oct 2018
View Details

c# Http请求之HttpClient

利用HttpClient进行Http请求,基于此,简单地封装了下:

有关更多的Http请求,请看这里:https://github.com/wangqiang3311/HttpRequestDemo from:http://www.cnblogs.com/wangqiang3311/p/8991214.html

龙生   07 Oct 2018
View Details
1 126 127 128 282