今天邮箱收到github的issue更新提醒，就在昨天，龙芯(loongson)的码农们已经让.NET Core 3.1的FlightFinder例子在MIPS64跑起来了，但是更复杂的程序还得继续改，预计在今年年底加入.NET 5.x（谨慎乐观）。

.NET 本身是完全开源，比Java还要开放（想想现在Google和Oracle关于Java的专利案还没结束呢），但是MS官方已经明确.NET Core和未来的版本不会支持MIPS的CPU指令集架构（龙芯就是用这个架构级），因为太小众了，要实现就得社区自己去写。

龙芯的团队从去年11月份跑Hello World到现在做了不少工作，看社区里的几位工程师也很努力，最终应该会支持（大概率版本会落后），这个值得肯定。但是，对于龙芯来说，社区和生态太难了，要不是去年“安可”要求，估计也不会刺激他们去支持.NET Core。好的结局是“安可”推广成功，gov和army里无关紧要的系统都用（核心系统因为复杂度，怕是很难用上）。

最最要命的是：技术发展太快了，龙芯所支持的服务器市场现在已经完全靠云计算了，这些云计算不可能采用龙芯等国产芯片，这也是为什么阿里要造出概念化的飞天国产云系统的原因——为了政策需要啊！

对于科学技术，我坚信市场化和资本化是最有效的驱动力，最近的SpaceX是又一个有力佐证。努力的人很多，最后大都做了前浪。

一、费马大定理

$$ x^n+y^n=z^n \mbox{(n=2,为毕达哥拉斯定理)} $$

二、欧拉公式

$$e^{i\pi} + 1 = 0$$

三、牛顿-莱布尼茨公式

$$ \int_a^bf(x){\rm d}x=F(b)-F(a) $$

四、黎曼zeta函数

整数形式

$$\zeta(p) = \sum_{n=1}^{\infty}{\frac{1}{n^p}}$$

复数形式

$$\zeta(s) = \sum_{n=1}^{\infty}{\frac{1}{n^s}} \mbox{ （其中，} s \in C \mbox{，且 } Re(z) > 1 \mbox{）}$$

插画版Kubernetes指南（小孩子也能看懂的kubernetes教程）
是根据一个视频翻译过来的，比较形象

编者按：Matt Butcher 是 Deis 的平台架构师，热爱哲学，咖啡和精雕细琢的代码。有一天女儿走进书房问他什么是 Kubernetes，于是就有了这本插画版的 Kubernetes 指南，讲述了勇敢的 Phippy（一个 PHP 应用），在 Kubernetes 的冒险故事，满满的父爱有木有！

某一天

有一天，女儿走进书房问我：『亲爱的爸爸，什么是 Kubernetes 呢？』

我回答她：『Kubernetes 是一个开源的 Docker 容器编排系统，它可以调度计算集群的节点，动态管理上面的作业，保证它们按用户期望的状态运行。通过使用「labels」和「pods」的概念，Kubernetes 将应用按逻辑单元进行分组，方便管理和服务发现。』

女儿更疑惑了……于是就有了这个故事。

给孩子的插画版 Kubernetes 指南

很久很久以前，有一个叫 Phippy 的 PHP 应用，她很单纯，只有一个页面。她住在一个托管服务里，周围还有很多可怕的应用，她都不认识，也不想去认识，但是他们却要共享这里的环境。所以，她一直都希能有一个属于自己的环境：一个可以称作 home 的 webserver。

每个应用的运行都要依赖一个环境，对于一个 PHP 应用来说，这个环境包括了一个 webserver，一个可读的文件系统和 PHP 的 engine。

有一天，一只可爱的鲸鱼拜访了 Phippy，他建议 Phippy 住在容器里。Phippy 听从了鲸鱼的建议搬家了，虽然这个容器看起来很好，但是……怎么说呢，就像是漂浮在海上的一个小房间一样，还是没有家的感觉。

不过容器倒是为应用提供了隔离的环境，在这个环境里应用就能运行起来。但是这些相互隔离的容器需要管理，也需要跟外面的世界沟通。共享的文件系统，网络，调度，负载均衡和资源分配都是挑战。

『抱歉……孩子……』鲸鱼耸耸肩，一摇尾消失在了海平面下…… Phippy 还没有来得及失望，就看到远方驶来一艘巨轮，掌舵的老船长非常威风。这艘船乍一看就是大了点，等到船走近了，Phippy 才发现船体两边挂满了皮筏。

老船长用充满智慧的语气对 Phippy 说：『你好，我是 Kube 船长』。

『Kubernetes』是希腊语中的船长，后来的『Cybernetic』和『Gubernatorial』这两个词就是从 Kubernetes 衍生来的。Kubernetes 项目由 Google 发起，旨在为生产环境中成千上万的容器，构建一个健壮的平台。

『您好，我是 Phippy。』

『很高兴认识你。』船长边说，边在 Phippy 身上放了一个 name tag。

Kubernetes 使用 label 作为『nametag』来区分事物，还可以根据 label 来查询。label 是开放式的：可以根据角色，稳定性或其它重要的特性来指定。

Kube 船长建议 Phippy 可以把她的容器搬到船上的 pod 里，Phippy 很高兴地接受了这个提议，把容器搬到了 Kube 的大船上。Phippy 感觉自己终于有家了。

在 Kubernetes 中，pod 代表着一个运行着的工作单元。通常，每个 pod 中只有一个容器，但有些情况下，如果几个容器是紧耦合的，这几个容器就会运行在同一个 pod 中。Kubernetes 承担了 pod 与外界环境通信的工作。

Phippy 对这一切都感到很新奇，同时她也有很多与众不同的关注点：『如果我想要复制自己该怎么做呢？按需的……任意次数的可以吗？』

『很简单。』船长说道，接着就给 Phippy 介绍起了 replication controller。

　　Replication controller 提供了一种管理任意数量 pod 的方式。一个 replication controller 包含了一个 pod 模板，这个模板可以被不限次数地复制。通过 replication controller，Kubernetes 可以管理 pod 的生命周期，包括扩/缩容，滚动部署和监控等功能。

Phippy 就这样在船上和自己的副本愉快地生活了好多天。但是每天只能面对自己的副本，这样的生活也太孤单了。

Kube 船长慷慨地笑道：『我有好东西给你。』

说着，Kube 船长就在 Phippy 的 replication controller 和船上其它地方之间建了一个隧道：『就算你们四处移动，这个隧道也会一直待在这里，它可以帮你找到其它 pod，其它 pod 也可以找到你。』

service 可以和 Kubernetes 环境中其它部分（包括其它 pod 和 replication controller）进行通信，告诉它们你的应用提供什么服务。Pod 可以四处移动，但是 service 的 IP 地址和端口号是不变的。而且其它应用可以通过 Kubernetes 的服务发现找到你的 service。

有了 service，Phippy 终于敢去船上其它地方去玩了，她很快就有了新朋友 Goldie。有一天，Goldie 送了 Phippy 一件礼物，没想到 Phippy 只看了一眼就哭了。

『你怎么哭了？』Goldie 问道。

『我太喜欢这个礼物了，可惜没地儿放……』Phippy 都开始抽泣了。Goldie 一听原来是这么回事，马上就告诉 Phippy：『为什么不放在一个 volume 里呢？』

Volume 代表了一块容器可以访问和存储信息的空间，对于应用来说，volume 是一个本地的文件系统。实际上，除了本地存储，Ceph、Gluster、Elastic Block Storage 和很多其它后端存储都可以作为 volume。

Phippy 渐渐地爱上了船上的生活，她很享受和新朋友的相处（Goldie 的每个 pod 副本也都很 nice）。但是回想起以前的生活，她又在想是不是可以有一点点私人空间呢？

Kube 船长很理解：『看起来你需要 namespace。』

Namespace 是 Kubernetes 内的分组机制。Service，pod，replication controller 和 volume 可以很容易地和 namespace 配合工作，但是 namespace 为集群中的组件间提供了一定程度的隔离。

于是，在 Kube 船长的船上，Phippy 和她的朋友们开始了海上的历险，最重要的是，Phippy 找到了自己的家。

从此，Phippy 过上了幸福的生活。
转载自：https://www.cnblogs.com/kouryoushine/articles/8007648.html

原作：Edison Zhou 恰童鞋骚年

一、Docker极简介绍

1.1 总体介绍

　　Docker 是一个开源的应用容器引擎，基于 Go 语言 并遵从Apache2.0协议开源。Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app），更重要的是容器性能开销极低。

简而言之> 容器是一个打包了应用服务的环境，它是一个轻量级的虚拟机，每一个容器由一组特定的应用和必要的依赖库组成。

　　Docker和传统虚拟化之间最大的区别在于：容器是在操作系统层面上实现虚拟化，即直接复用本地主机的操作系统；而传统虚拟化则是在硬件层面实现，如VMware vShpere, Xen及Citrix等。

1.2 Docker结构
　　Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和创建Docker容器。
　　Docker 容器通过 Docker 镜像来创建。
　　容器与镜像的关系类似于面向对象编程中的对象与类。　　
　　Docker的架构如下图所示，Client 通过接口与Server进程通信实现容器的构建，运行和发布。Client和Server可以运行在同一台集群，也可以通过跨主机实现远程通信。

　　具体详细内容，请浏览：《几张图帮你理解Docker基本原理及快速入门》

二、Docker的安装

　　（1）准备一台Linux主机，这里以CentOS 7.2为例。当然，你也可以使用Windows，不过你得确保是Windows 10 pro版本及以上，且安装了Hyper-V等一系列的相关软件。

　　（2）安装docker

　　# yum install docker

　　（3）启动docker服务

　　# systemctl start docker.sevice
　　（4）配置开机启动并验证
　　# systemctl enable docker.service
　　验证：查看docker版本信息
　　# docker version
　　（5）配置docker加速器 => 原因你懂得，不设置慢死你，云服务器除外

　　# vim /etc/docker/daemon.json

{

"registry-mirrors": ["https://d8b3zdiw.mirror.aliyuncs.com"]

}

　　然后重启docker服务

　　# systemctl daemon-reload

　　# systemctl restart docker

　　（6）Hello World

　　# docker run hello-world

三、ASP.NET Core on Docker配置

　　（1）拉取dotnet/aspnetcore的最新镜像，这里以aspnetcore 2.0为例

　　# docker pull microsoft/aspnetcore:2.0

　　PS：如果要拉取最新版本（比如.net core 2.1），可以将版本号改为aspnetcore:latest

　　如果你想要拉取更多microsoft的镜像，那么搜索一下把：# docker search microsoft

　　拉取了不想要的镜像，那么删除一个吧，如：# docker rmi imagesID

　　拉取之后，验证一下是否拉取成功了：# docker images

　　（2）现在我们进入VS中为我们的一个ASP.NET Core WebAPI编辑一个Dockerfile

父镜像

FROM microsoft/aspnetcore:2.0# 设置工作目录
WORKDIR /app

复制发布文件到/app下

COPY . /app

设置端口

EXPOSE 8810# 使用dotnet Manulife.DNC.MSAD.NB.AgentService.dll来运行ASP.NET Core项目，注意大小写
ENTRYPOINT ["dotnet", "Manulife.CD.MSAD.NB.AgentService.dll", "--server.urls", "http://*:8810"]

　　（3）发布这个ASP.NET Core WebAPI，并将Release文件传送到Linux服务器中（你可以选择xFTP或者WinScp等工具）

　　（4）进入上图的AgentService目录中，开始打包docker镜像

　　# docker build -t agentservice-container:1.0 . => 不要忘记后面还有一个点.
　　此刻再次验证：# docker images

　　（5）万里长征最后一步：运行docker
　　# docker run -name agentservice -d -p 8810:8810 agentservice-container:1.0

　　这里的两个端口号分别是宿主机和容器的映射，前一个是你在外部访问的端口号，后一个是你要映射到docker容器中的端口号，切记和我们在Dockerfile中暴露出来的端口号保持一致。
　　PS：这里如果docker run失败后再次运行会提示名称已存在，可以使用以下命令来删除容器
　　# docker rm -f [dockername]
　　如果想要docker容器在非正常退出后自动重启，可以加上--restart选项，例如下面：
　　# docker run --name agentservice -d -p 8810:8810 agentservice-container:1.0 --restart=always

　　（6）验证docker运行效果

　　方式一：在宿主机验证

　　方式二：在远程客户端通过浏览器访问

四、Supervisor守护进程

　　此部分主要针对于在Linux上的dotnet core应用程序，保证程序在异常或者是电脑重启的时候仍然能够正常访问。大家可以浏览杨晓东的《ASP.NET Core Linux下为dotnet创建守护进程》以及focus-lei的《在docker上运行.net core程序》来学习，这里就不再赘述了。
参考资料
（1）菜鸟教程，《Docker教程》
（2）杨晓东，《ASP.NET Core Docker部署》，《ASP.NET Core Linux下为dotnet创建守护进程》
（3）李朝强，《Docker打包ASP.NET Core应用，在CentOS上运行》
（4）圣杰，《.NET Core容器化@Docker》
（5）focus-lei，《在Docker上运行.net core程序》

用Windbg来分析.Net程序的dump

1. 什么是Windbg

WinDbg是微软发布的一款相当优秀的源码级(source-level)调试工具，可以用于Kernel模式调试和用户模式调试，还可以调试Dump文件。
WinDbg是微软很重要的诊断调试工具: 可以查看源代码、设置断点、查看变量, 查看调用堆栈及内存情况。
Dump文件是进程的内存镜像, 可以把程序的执行状态通过调试器保存到dump文件中

2. Windbg可以解决以下问题

◆ 内存高
◆ CPU高
◆ 程序异常
◆ 程序Hang死

3. 使用windbg进行调试分析的两种方式

使用windbg调试器attach到需要调试的进程。(会暂停进程的运行)
抓取进程的dump文件，使用windbg分析dump

下载地址:https://technet.microsoft.com/en-us/sysinternals/dd996900

下载之后为压缩包，将文件解压。通过dos命令来生成dump文件。下面为一条语句为示例

procdump -ma -c 0 -s 3 -n 2 sqlservr.exe -o E:\dumps\

这条语句的意思为：当sqkservr.exe这个进程运行时间cpu的占用超过0%，时间超过3秒，则在E:\dumps下生成一个dump文件。一直到生成2个为止。下面为命令介绍

-ma 生成full dump, 即包括进程的所有内存. 默认的dump格式包括线程和句柄信息.
-c 在CPU使用率到达这个阀值的时候, 生成dump文件.
-s CPU阀值必须持续多少秒才抓取dump文件.
-n 在该工具退出之前要抓取多少个dump文件.
-o dump文件保存目录.
Sqlservr.exe可替换为进程的ID

以下文章来源于DotNET技术圈 ，作者RICKY LEEKS

1.小对象怎么处理的？

小型.NET对象被分配到小型对象堆（SOH）上。其中有3种：第0代，第1代和第2代。对象根据其寿命向上移动。

将新对象放在Gen 0上。当Gen 0充满时，.NET垃圾收集器（GC）运行，处理不再需要的对象，并将其他所有内容移至Gen1。如果Gen 1充满，则GC再次运行，也可以将Gen 1中的对象移动到Gen 2中。

当Gen 2变满时，将发生GC完全运行。这将清除不需要的Gen 2对象，将Gen 1对象移至Gen 2，然后将Gen 0对象移至Gen 1，最后清除所有未引用的内容。每次运行GC之后，都会压缩受影响的堆，以将仍在使用的内存保持在一起。

这种代代相传的方法可确保事情高效运行-耗时的压缩过程仅在绝对必要时才会发生。

注意：如果您在Gen 2中看到大量的内存，则表明内存已被保留很长时间，并且可能存在内存问题。这是内存分析工具可以派上用场的地方。

2.较大的对象会怎样？

大于85 KB的对象被分配到大对象堆（LOH）。由于复制大块内存的开销，它们没有被压缩。当发生完整的GC时，未使用的LOH对象的地址范围将记录在可用空间分配表中。

分配新对象后，将在此可用空间表中检查足以容纳该对象的地址范围。如果存在，则将对象分配到那里，如果不存在，则将对象分配到下一个可用空间。

由于对象不太可能是空地址范围的确切大小，因此对象之间几乎总是会留有小块内存，从而导致碎片。如果这些块小于85 KB，则根本没有重用的可能性。因此，随着分配需求的增加，即使碎片空间仍然可用，也会保留新的段。

此外，当需要分配大对象时，.NET还是倾向于将对象附加到末尾，而不是运行昂贵的Gen 2 GC。这对性能有好处，但是是导致内存碎片的重要原因

3.垃圾收集器可以在不同的模式下运行以优化性能

.NET通过为GC提供多种模式来解决性能与堆效率之间的权衡问题。

工作站模式为用户提供了最大的响应速度，并减少了由于GC造成的暂停。它可以作为“并发”或“非并发”运行，指的是运行GC的线程。默认值为并发，它为GC使用单独的线程，因此应用程序可以在GC运行时继续执行。

服务器模式可为服务器环境提供最大的吞吐量，可伸缩性和性能。在服务器模式下，段大小和生成阈值通常比工作站模式大得多，这反映了对服务器的更高要求。

服务器模式在多个线程上并行运行垃圾回收，为每个逻辑处理器分配一个单独的SOH和LOH，以防止线程相互干扰。

.NET框架提供了一种交叉引用机制，因此对象仍然可以在堆之间相互引用。但是，由于应用程序响应能力不是服务器模式的直接目标，因此在GC期间，所有应用程序线程都将被挂起。

4.引用不足会在性能和内存效率之间折衷

弱对象引用了GC根的替代来源，使您可以保留对象，同时在GC需要时可以收集对象。它们是代码性能和内存效率之间的折衷。创建对象需要占用CPU时间，但保持加载状态需要占用内存。

弱引用特别适用于大型数据结构。例如，假设您有一个允许用户浏览大型数据结构的应用程序，他们可能会返回其中的一些数据。您可以将任何强引用转换为他们浏览的结构为弱引用。如果用户返回到这些结构，则可以使用它们，但如果没有，GC可以根据需要回收内存。

5.对象固定可以创建在托管和非托管代码之间传递的引用

.NET使用一种称为GCHandle的结构来跟踪堆对象。GCHandle可用于在托管域和非托管域之间传递对象引用，.NET维护一个GCHandles表以实现此目的。GCHandle有四种类型，包括固定的，用于将对象固定在内存中的特定地址。

对象固定的主要问题是它可能导致SOH碎片化。如果将对象固定在GC期间，则根据定义，该对象无法重定位。根据您使用固定的方式，它会降低压缩的效率，在堆中留下间隙。避免这种情况的最佳策略是在很短的时间内锁定，然后释放。

这一个多月以来，我投入了大量的时间回顾和复习本科基础数学课程，重点是《数学分析》、《高等代数》、《解析几何》、《概率论与数理统计》、《数值分析》、《数学模型》，并且延申阅读了这几个学科的历史。我最关心的是数学模型，这个也是我大学里除了三门基础课程之外学得最好的一门课程，而且我投入了大量时间数学模型的学习，并且参加了校级、国级和美国数学建模比赛，分别获得一等奖、二等奖和一等奖。

所谓数学模型，其实简单地说就是：使用数学方法解决实际应用问题。除了常见的数学模型，还有其他大量地借用数学方法来解决实际问题的例子，比如爱因斯坦的相对论，其实就是借用非欧几何的数学理论来解决物理问题。关于常见的数学模型，已经有人进行了非常好的整理：线性规划、整数规划、非线性规划、 图与网络模型、插值与拟合、微分方程建模、数理统计、时间序列、支持向量机、多元分析、偏最小二乘回归分析、现代优化算法（模拟退火、遗传算法）、数字图像处理、 综合评价与决策方法、预测方法（微分方程、灰色度预测、差分方程、马尔可夫预测、插值与拟合、神经网络）。

我后续会比较深入地重新捡起这些算法和模型，并且运用到实际生活中，我这里的实际生活，就是针对实实在在发生和进行的事情。

三百五十多年前，牛顿为躲避瘟疫回到老家，酝酿出了《自然哲学之数学原理》。2020年初，我因新冠疫情躲在北京郊区近两个月，闲暇之余却只是建了几个模、(重)读了几本书。从先哲们那里获取心力，只是为了让自己思想变得更坚定。