Author: haoransun
WeChat: SHR—97
图片&知识点来源：B站

一. 学术界常见缩写

1.1 缩写

CNS
Cell、Nature、Science是三个最负盛名的学术期刊，其实都是SCI的收录期刊。即我们可以通过SCI这个工具检索到里面收录的所有期刊的文章。

JCR
JCR：Journal Citation Reports。即期刊引用报告。JCR对包括SCI收录的核心期刊(光盘版)在内的8000多种期刊(网络版)之间的引用和被引用数据进行统计、运算，并针对每种期刊定义了影响因子（Impact Factor）等指数加以报道。

一种期刊的影响因子，指的是该刊前二年发表的文献在当前年的平均被引用次数。一种刊物的影响因子越高，也即其刊载的文献被引用率越高，一方面说明这些文献报道的研究成果影响力大，另一方面也反映该刊物的学术水平高。因此，JCR以其大量的期刊统计数据及计算的影响因子等指数，而成为一种期刊评价工具。图书馆可根据JCR提供的数据制定期刊引进政策；论文作者可根据期刊的影响因子排名决定投稿方向。

转载自：https://zhuanlan.zhihu.com/p/32459776

前言

至少30年以前，一些软件设计人员就已经意识到领域建模和设计的重要性，并形成一种思潮，Eric Evans将其定义为领域驱动设计（Domain-Driven Design，简称DDD）。在互联网开发“小步快跑，迭代试错”的大环境下，DDD似乎是一种比较“古老而缓慢”的思想。然而，由于互联网公司也逐渐深入实体经济，业务日益复杂，我们在开发中也越来越多地遇到传统行业软件开发中所面临的问题。本文就先来讲一下这些问题，然后再尝试在实践中用DDD的思想来解决这些问题。

转载自：https://www.jianshu.com/p/147f2d170377

一、Hello DDD

刚开始接触学习「DDD - 领域驱动」的时候，我被各种新颖的概念所吸引：「领域」、「领域驱动」、「子域」、「聚合」、「聚合根」、「值对象」、「通用语言」…..总之一大堆有关的、无关的概念从我的脑海经过，其中不乏让我陷入思考的地方，我原以为我会很开心地 “享用” 这些新知识带给我的营养

可事实上，我为学习「DDD - 领域驱动」付出了很多的精力，我尝试用「DDD CRUD」、「DDD vs CRUD」、「Domain-Driven Design」、「DDD CQRS」、「领域驱动设计」等等一系列的关键字搜集我想要的资料_（翻遍了 Google 前排的所有文章&手动感谢谷歌让我能获得一些精彩的文章）_，可似乎都不太近人意，一方面这个「新概念」我对它的困惑太多了，另一方面真正「落地」并实践起来的经验有很少是可以直接借鉴的，再结合一些实际的场景（没有人解答），我感到更加困惑。

转载自 https://zhuanlan.zhihu.com/p/91525839

背景

正所谓有人的地方就有江湖，有设计的地方也一定会有架构。如果你是一位软件行业的老鸟，你一定会有这样的经历：一个业务的初期，普通的 CRUD 就能满足，业务线也很短，此时系统的一切都看起来很 nice，但随着迭代的不断演化，以及业务逻辑越来越复杂，我们的系统也越来越冗杂，模块彼此关联，甚至没有人能描述清楚每个细节。当新需求需要修改一个功能时，往往光回顾该功能涉及的流程就需要很长时间，更别提修改带来的不可预知的影响面。于是 RD 就加开关，小心翼翼地切流量上线，一有问题赶紧关闭开关。

面对此般场景，你要么跑路，要么重构。重构是克服演进式设计中大杂烩问题的主力，通过在单独的类及方法级别上做一系列小步重构来完成，我们可以很容易重构出一个独立的类来放某些通用的逻辑，但是，你会发现你很难给它一个业务上的含义，只能给予一个技术维度描绘的含义。你正在一边重构一边给后人挖坑。

在互联网开发“小步快跑，迭代试错”的大环境下，DDD 似乎是一种比较“古老而缓慢”的思想。然而，由于互联网公司也逐渐深入实体经济，业务日益复杂，我们在开发中也越来越多地遇到传统行业软件开发中所面临的问题。

怎么解决这个问题呢？其实法宝就是今天的主题，领域驱动设计！！

转载自：https://zhuanlan.zhihu.com/p/200876311

领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示。领域模型也称为概念模型、领域对象模型和分析对象模型。《UML和模式应用》

我们在日常开发中，经常针对一些功能点争论“这个功能不应该我改，应该是你那边改”，最终被妥协改了之后都改不明白为什么这个功能要在自己这边改。区别于传统的架构设计，领域驱动设计（DDD）也许在这个时候能帮助你做到清晰的划分。

转载自：http://www.uml.org.cn/zjjs/202001023.asp

前言

云计算时代出现了大量XaaS形式的概念,从IaaS、PaaS、SaaS到容器云引领的CaaS,再到火热的微服务架构,以及现在越来越多被谈起的Serverless和FaaS,我们正在经历?一个技术飞速变革的时代。

一、什么是Faas

云计算时代出现了大量XaaS形式的概念，从IaaS(Infrastructure as a Service)、PaaS(Platform as a Service)、SaaS(Software as a Service)到容器云引领的CaaS(Containers as a Service)，再到火热的微服务架构，它们都在试着将各种软、硬件资源等抽象为一种服务提供给开发者使用，让他们不再担心基础设施、资源需求、中间件等等，在减轻心智负担的同时更好地专注于业务。FaaS是Functions as a Service的简称，它往往和无服务架构(Serverless Architecture)一同被提起。

Serverless的概念刚刚出现在HackerNews时并不为大众所接受。后来随着微服务和事件驱动架构的发展才慢慢引起关注。Serverless并不是说没有服务器参与，它通过将复杂的服务器架构透明化，使开发者专注于“要做什么”，从而强调了减少开发者对服务器等计算资源的关注、工作粒度从服务器切换到任务的思想。2006年第一个支持“随用随付”的代码执行平台Zimki问世。2014年亚马逊AWS推出了Lambda成为最主要的无服务架构的代表。接着Google、IBM和Microsoft也纷纷推出了各自支持Serverless的平台。

转载自 原创作者 微信号-mhcoding

1. 为什么要用分布式ID？

在说分布式ID的具体实现之前，我们来简单分析一下为什么用分布式ID？分布式ID应该满足哪些特征？

1、什么是分布式ID？

拿MySQL数据库举个栗子：

在我们业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。

但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求；特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。

前言

在Docker中创建镜像最常用的方式，就是使用Dockerfile。Dockerfile是一个Docker镜像的描述文件，我们可以理解成火箭发射的A、B、C、D…的步骤。Dockerfile其内部包含了一条条的指令，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。

组成部分

前言

1. 前言

Linux内核支持6种名称空间。

• UTS：主机名+域名
• USER：用户
• Mount：挂载文件系统
• IPC：进程间通信
• Pid：进程ID
• Net：网络

OVS：OpenVSwitch
SDN：软件驱动网络
Overlay Network:基于隧道叠加实现的另外一层网络通信。

C1要与C5通信，将报文发送给bridge上，由bridge发送给物理网卡，经由隧道转发。