Posts

这三周来牺牲社交时间，我亲自出马、带着团队三名精干主力在“中标麒麟龙芯”下编译.Net Core 3.0、并调试程序，编译通过但Bug太多，以失败而告终，最后放弃这个平台，这不是我们的问题，这是龙芯团队的问题，他们的CPU对彻底开源的.NET支持台还很差(也许明年会好些)，不过目前我们支持“中标麒麟兆芯”，这个平台也完全符合安可要求。 从我接触到的情况来看，目前最鸡血的是那些国字号相关的企业，不过如果不涉密，但大部分也只是买来应付检查，因为国产服务器真的是几乎不能用。还有一些比较聪明的单位，直接购买云国产操作系统，但是这些国产云操作系统就是一个幌子，因为它们也是跑在“洋芯片”、寄生在“洋软件”下面而已。 Java的码农请别吐槽C#，两门语言都是“美帝”发明的开发语言哦，要说彻底支持符合国产要求，别忘了Java的SDK还有专利费，而且Java的拥有者Oracle告谷歌的侵权诉讼案还没结束呢，哈哈。 另外，很想对那些摇着民族主义旗号大喊国产的人，有本事从应用软件到开发语言彻底国产，还有哦，wifi现在澳洲公司还在收专利费、互联网也是MIT的发明、Apache基金会的总部现在还设在美国的马里兰州……这只是一场分蛋糕大盛宴，曲终人必散，苦的是那些重复造轮子的码农，还好我们已经脱离苦海。

这几天又重新学习复习了一下数学基础：逻辑主义、形式主义和直觉主义。我自己当然更倾向于基于公理化集合论的逻辑主义，这也是目前大部分数学家的选择。 一、数学基础 数学上，数学基础一词有时候用于数学的特定领域，例如数理逻辑，公理化集合论，证明论，模型论，和递归论（可计算性理论）。但是寻求数学的基础也是数学哲学的中心问题：在什么终极基础上命题可以称为真? 目前占统治地位的数学范式是基于公理化集合论和形式逻辑的。实际上，几乎所有现在的数学定理都可以表述为集合论下的定理。在这个观点下，所谓数学命题的真实性，不过就是该命题可以从集合论公理使用形式逻辑推导出来。 二、公理化集合论 基础集合论可以用非正式的、直觉的方式学习，在小学中就可以用文氏图说明。基础集合论直观地假设集合就是一群符合任意特定条件的对象的组合，但此假设会造成悖论。最简单及著名的是罗素悖论及布拉利-福尔蒂悖论。公理集合论的形成就是为了避免这些集合论的悖论。 许多数学家研究的公理集合论系统假设所有的集合形成累计层次。这类的系统可分为二类： 1、只由集合构成：这类系统包括最常用的公理集合论：含选择公理的策梅洛-弗兰克尔集合论（ZFC），由亚伯拉罕·弗兰克尔和陶拉尔夫·斯科伦扩展了策梅罗集合论所得。其他和ZFC有关的集合论有： 1）、策梅洛集合论是由德国数学家恩斯特·策梅洛创立，将分类公理代替替代公理。 2）、广义集合论，策梅洛集合论的一小部分，已足以处理皮亚诺公理及有限集合。 3）、克里普克-普拉特克集理论，省略了无穷公理、幂集公理和选择公理，削弱了分类公理和替代公理的公理架构。 2、由集合和真类构成：这类系统包括冯·诺伊曼-博内斯-哥德尔集合论，是设计生成同 ZFC同样结果的集合论公理系统，但只有有限数目的公理而不使用公理模式。单论只涉及集合的内容，此理论的强度和ZFC相当。另外比ZFC强的Morse-Kelley集合论及Tarski–Grothendieck集合论也属于这一类。 三、选择公理 选择公理：对于所有的集族，均存在选择函数。 罗素解释：假设有许多（甚至是无限）双鞋子，则我们可以选取每双鞋左边的鞋子构成一个具体的选择。然而，假设有无限双袜子（假设每双袜子都没有可区分的特征），在对于所有的集族，均存在选择函数。 哥德尔证明了选择公理与ZF的相对协调性。保罗·寇恩用力迫法证明了选择公理独立于ZF。也就是说：哥德尔和寇恩证明了，无论接受选择公理与否，都不会导致矛盾，只是身处不同的『数学世界』而已。 不过，除了一些研究集合论的数学家和逻辑学家以外，大部分数学家都选择接受选择公理，因为在含有选择公理的数学世界里，事情会简单一些。

你是否还在为微服务应该拆多小而争论不休？到底如何才能设计出收放自如的微服务？怎样才能保证业务领域模型与代码模型的一致性？或许本文能帮你找到答案。 本文是基于 DDD 的微服务设计和开发实战篇，通过借鉴领域驱动设计思想，指导微服务项目团队进行设计和开发（理论篇详见《当中台遇上 DDD，我们该如何设计微服务？》）。本文包括三部分内容：第一部分讲述领域驱动设计基本知识，包括：分层架构、服务视图、数据视图和领域事件发布和订阅等；第二部分讲述微服务设计方法、过程、模板、代码目录、设计原则等内容；最后部分以一个项目为例讲述基于 DDD 的微服务设计过程。 目标 本文采用 DDD（领域驱动设计）作为微服务设计指导思想，通过事件风暴建立领域模型，合理划分领域逻辑和物理边界，建立领域对象及服务矩阵和服务架构图，定义符合 DDD 分层架构思想的代码结构模型，保证业务模型与代码模型的一致性。通过上述设计思想、方法和过程，指导团队按照 DDD 设计思想完成微服务设计和开发。 通过领域模型和 DDD 的分层思想，屏蔽外部变化对领域逻辑的影响，确保交付的软件产品是边界清晰的微服务，而不是内部边界依然混乱的小单体。在需求和设计变化时，可以轻松的完成微服务的开发、拆分和组合，确保微服务不易受外部变化的影响，并稳定运行。 适用范围 本文适用于按照 DDD 设计方法进行微服务设计和开发的项目及相关人员。 以下情况不适用： “我们的目标是按期盖出一栋大楼来，不要跟我提什么方法，有这啰嗦的时间，还不如抓紧点时间搬砖，把楼给我快点盖好！”。 “我的工作就是让软件运行起来，能工作一切就 OK！我不需要那么多约束，什么设计方法、扩展性、业务变化、领域模型、响应能力与我无关。别耽误工期啦！先上线再说！”。 “好的软件是自己演进出来的，我们不需要设计！”。 哈哈，开个玩笑啦！其实设计不会花太多时间的！ 正文内容 不耽误大家时间了，言归正传。 DDD 分层架构视图 DDD 分层架构包括：展现层、应用层、领域层和基础层。 基于DDD的微服务设计和开发实战 DDD 分层架构各层职能如下： 展现层 展现层负责向用户显示信息和解释用户指令。 应用层 应用层是很薄的一层，主要面向用户用例操作，协调和指挥领域对象来完成业务逻辑。应用层也是与其他系统的应用层进行交互的必要渠道。应用层服务尽量简单，它不包含业务规则或知识，只为下一层的领域对象协调任务，使它们互相协作。应用层还可进行安全认证、权限校验、分布式和持久化事务控制或向外部应用发送基于事件的消息等。 领域层 领域层是软件的核心所在，它实现全部业务逻辑并且通过各种校验手段保证业务正确性。它包含业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。它负责表达业务概念、业务状态以及业务规则，具体表现形式就是领域模型。 基础层 基础层为各层提供通用的技术能力，包括：为应用层传递消息、提供 API 管理，为领域层提供数据库持久化机制等。它还能通过技术框架来支持各层之间的交互。 服务视图 微服务内的服务视图 微服务内有 Facade 接口、应用服务、领域服务和基础服务，各层服务协同配合，为外部提供服务。 基于DDD的微服务设计和开发实战 1、接口服务 接口服务位于用户接口层，用于处理用户发送的 Restful 请求和解析用户输入的配置文件等，并将信息传递给应用层。 2、应用服务 应用服务位于应用层。用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装。 应用层的服务包括应用服务和领域事件相关服务。 应用服务可对微服务内的领域服务以及微服务外的应用服务进行组合和编排，或者对基础层如文件、缓存等数据直接操作形成应用服务，对外提供粗粒度的服务。 领域事件服务包括两类：领域事件的发布和订阅。通过事件总线和消息队列实现异步数据传输，实现微服务之间的解耦。 3、领域服务 领域服务位于领域层，为完成领域中跨实体或值对象的操作转换而封装的服务，领域服务以与实体和值对象相同的方式参与实施过程。 领域服务对同一个实体的一个或多个方法进行组合和封装，或对多个不同实体的操作进行组合或编排，对外暴露成领域服务。领域服务封装了核心的业务逻辑。实体自身的行为在实体类内部实现，向上封装成领域服务暴露。 为隐藏领域层的业务逻辑实现，所有领域方法和服务等均须通过领域服务对外暴露。 为实现微服务内聚合之间的解耦，原则上禁止跨聚合的领域服务调用和跨聚合的数据相互关联。 4、基础服务 基础服务位于基础层。为各层提供资源服务（如数据库、缓存等），实现各层的解耦，降低外部资源变化对业务逻辑的影响。 基础服务主要为仓储服务，通过依赖反转的方式为各层提供基础资源服务，领域服务和应用服务调用仓储服务接口，利用仓储实现持久化数据对象或直接访问基础资源。 微服务外的服务视图 ...

今天邮箱收到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是又一个有力佐证。努力的人很多，最后大都做了前浪。

插画版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 发起，旨在为生产环境中成千上万的容器，构建一个健壮的平台。 ...

一、费马大定理 $$ 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{）}$$

原作：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 ...

以下文章来源于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期间，则根据定义，该对象无法重定位。根据您使用固定的方式，它会降低压缩的效率，在堆中留下间隙。避免这种情况的最佳策略是在很短的时间内锁定，然后释放。

用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

这一个多月以来，我投入了大量的时间回顾和复习本科基础数学课程，重点是《数学分析》、《高等代数》、《解析几何》、《概率论与数理统计》、《数值分析》、《数学模型》，并且延申阅读了这几个学科的历史。我最关心的是数学模型，这个也是我大学里除了三门基础课程之外学得最好的一门课程，而且我投入了大量时间数学模型的学习，并且参加了校级、国级和美国数学建模比赛，分别获得一等奖、二等奖和一等奖。 所谓数学模型，其实简单地说就是：使用数学方法解决实际应用问题。除了常见的数学模型，还有其他大量地借用数学方法来解决实际问题的例子，比如爱因斯坦的相对论，其实就是借用非欧几何的数学理论来解决物理问题。关于常见的数学模型，已经有人进行了非常好的整理：线性规划、整数规划、非线性规划、 图与网络模型、插值与拟合、微分方程建模、数理统计、时间序列、支持向量机、多元分析、偏最小二乘回归分析、现代优化算法（模拟退火、遗传算法）、数字图像处理、 综合评价与决策方法、预测方法（微分方程、灰色度预测、差分方程、马尔可夫预测、插值与拟合、神经网络）。 我后续会比较深入地重新捡起这些算法和模型，并且运用到实际生活中，我这里的实际生活，就是针对实实在在发生和进行的事情。