IT瘾程序员推荐

大模型真的加快了程序员的编程速度？

Wed, 24 Dec 2025 00:58:19 CST

MIT Technology Review 采访逾 30 名开发者、科技公司高管、分析师和研究人员后发现，基于大模型的 AI 工具是否加快程序员编程速度不是一个一锤定音的问题。随着一线程序员认识到大模型的局限性，他们对 AI 工具的狂热开始消退。众多研究表明，AI 工具所宣称的生产力提升可能只是一种假象。GitClear 的数据显示 2022 年以来工程师所写代码的持久性——数周内代码不会被删除或重写——提高约 10%，这一改进可能需要归功于 AI。但与此同时，代码的多项质量指标在快速下降。编程问答平台 Stack Overflow 的调查首次显示对 AI 工具的信任度和好感度显著下降。程序员普遍认同 AI 工具的优势在于生成“样板代码”，编写测试、修 bug 以及向新手解释不熟悉的代码。但对于经验丰富的程序员而言，此类任务只占工作量的一小部分，AI 工具对于解决复杂难题帮助不大。基于大模型的 AI 工具也不可避免存在幻觉，它们生成的代码看起来完美，因此很难发现错误。所以使用 AI 工具就像是玩老虎机，有的时候大有帮助，但其它情况可能完全不可靠。

我认识的“最差”程序员

Mon, 24 Mar 2025 17:34:33 CST

《我认识的“最差”程序员》

衡量开发者生产力最棒的一点是，你能快速识别出差劲的程序员。今天我要和你讲讲我所认识的最差程序员，以及为什么我拼了命也要把他留在团队中。

几年前，我在 Twitter/X 上写过一篇关于我认识的最好程序员的帖子（也许我该把那写成一篇博客文章）。既然提到了最好的程序员，现在再说说最差的，也算公平。他的名字叫蒂姆·麦金农（Tim Mackinnon），我想让你知道他的生产力指标到底有多差。

当时我们在一家著名的软件咨询公司，为一家大型银行工作。这家银行决定引入个人绩效指标，美其名曰“用于绩效评估和个人发展”。经过管理层慎重讨论，他们知道不能简单地用代码行数或发现bug数量来衡量，因为这些指标太容易被投机取巧。

我们选择的衡量方式是统计每个人交付的用户故事数量（或者故事点数，具体已经记不清了，也不重要），因为它们代表了业务价值。当时用类似 Jira 的工具，每个开发者都会在自己的故事上签名，这让生成生产力指标变得极其方便。

接下来我们说说蒂姆。蒂姆的分数始终是零。没错，就是零！不是分数低，也不是下降趋势，而是彻彻底底的零分。每周都是这样，每个迭代都是这样，零分。

很明显，蒂姆必须走人了。经理迅速得出这个结论，并且让我去安排开除蒂姆，换一个真正能交付故事的人。

而我明确拒绝了这个要求。这甚至不是个艰难的决定，我只是很坚定地说了“不”。

原因很简单，蒂姆的生产力分数为零，是因为他从来没签过任何一个故事。他每天都在做另一件事：与不同的队友进行结对编程。

跟经验少的程序员搭档时，他会耐心地让他们主导，并通过启发式的方式引导他们找到解决方案。他不会强行灌输自己的想法，而是巧妙地通过苏格拉底式的提问，比如“如果这样做会怎样？”“还能怎样做得更好？”等等，引导他们逐渐获得洞察并真正学到东西。

与资深开发者搭档时，则更像是一场思想的碰撞、共同创造——每个人带着不同的视角来看待问题，最终得出比单独工作更优秀的方案。蒂姆本身就是个厉害的程序员，每次和他结对，你都会学到新东西。

其实，蒂姆交付的并不是软件，他交付的是一支能够持续交付高质量软件的团队。正因为有他存在，整个团队变得更加高效、更有生产力、更统一、更专业，也更有趣。

我向经理解释了这一切，并邀请他偶尔过来亲眼看看我们的工作。当经理来到我们团队时，总能看到蒂姆和不同的人坐在一起，专注于其他人的任务。你可以确信，只要蒂姆参与了，这个任务的质量就会显著提升，交付的周期明显缩短——是的，只要有足够的纪律，你完全能做到质量更高、速度更快且成本更低。

最终，我们把蒂姆留了下来。同时，我们悄悄放弃了个人生产力指标，改用团队责任制，关注并庆祝团队作为整体带给组织的业务成果。

总结一下（tl;dr）：

你当然可以衡量生产力，我完全支持对工作成果负责的态度。最理想的方式是直接衡量以美元为单位的业务影响，比如创造了多少价值、节省了多少成本、保护了多少收益。但这通常不容易做到，因此用一些间接的业务指标也是可以的。

但是，千万别试图在一个复杂的、适应性的系统里衡量个体的贡献，因为这个问题的前提本身就是错的。

例如，DORA 指标的核心在于衡量工作系统本身，比如组织文化或技术变更流入生产的效率。它衡量的是整个引擎，而不是单独的某个活塞，因为单独评估毫无意义。

IBM CEO：AI 短期内不会取代程序员

Mon, 24 Mar 2025 10:15:57 CST

IBM CEO：AI 短期内不会取代程序员

作者：凯尔·维格斯

IBM 首席执行官阿尔温德·克里希纳（Arvind Krishna）表示，尽管特朗普政府曾大力抨击全球化，但全球贸易并没有消亡。相反，他认为美国经济增长的关键恰恰在于积极拥抱国际贸易。

在3月11日 SXSW 的访谈中，克里希纳表示：

「我坚信全球贸易的重要性，这个观点其实可以追溯到19世纪的经济学家。他们当时就发现，每当全球贸易额增加10%，当地GDP就能提升1%。因此，要想真正优化本地经济增长，就必须积极参与全球贸易。」

克里希纳强调，全球贸易的繁荣与人才的国际流动密不可分。他指出，美国政府和部分支持者曾主张对外国留学生和H-1B签证实行更严格限制，声称这些外国劳动力会削弱美国公民的就业优势。

对此，克里希纳表示：

「我们希望全球人才带着他们的知识和技能来到美国，同时我们也要培养自己的本地人才。然而，如果无法吸引全球顶尖的人才，让本地人才有机会学习与成长，本地人才的培养就会受到限制。因此，美国应该成为国际人才中心，并制定与此相适应的人才政策。」

在这场内容丰富的访谈中，克里希纳不仅谈及了地缘政治问题，也提到了备受关注的人工智能（AI）。在他看来，AI 是一种有价值的技术，但绝不是万能的解决方案。

克里希纳对近期 Anthropic 公司 CEO 达里奥·阿莫迪（Dario Amodei）的预测表示了不同意见。此前阿莫迪预测，在未来3到6个月内，90%的代码可能都会由AI自动生成。

而克里希纳则认为：

「我觉得实际数字更可能是20%到30%的代码会由AI编写，而绝不是90%。简单的场景确实可能很容易由AI完成，但也存在大量复杂的场景，AI根本做不到。」

克里希纳进一步指出，AI最终会提高程序员的工作效率，而非像一些AI批评者担忧的那样完全取代编程岗位：

「如果你能让现有人员多写30%的代码，你会因此减少还是增加代码总量呢？历史表明，更高效的公司往往能扩大市场份额，从而生产更多产品，最终获得更大的市场优势。」

当然，IBM 也有理由强调 AI 对就业不构成威胁，因为该公司自身就提供各种 AI 产品和服务，包括辅助编程工具。

克里希纳这番话也稍显自相矛盾。早在2023年，他曾公开表示，IBM 计划暂停后台部门的招聘工作，因为公司预计这些岗位很快就能被 AI 技术所取代。

谈及AI取代人类工作的争议时，克里希纳将此类争论比作早年计算器替代数学家，或Photoshop替代艺术家的担忧。他承认AI在知识产权领域仍存在许多尚未解决的问题，但强调这项技术本质上仍是一股积极而且增强人类能力的力量：

「AI只是一个工具。当所有人借助这些工具做出更高质量的产品时，最终受益的是广大消费者，因为他们能够享受到品质更高的产品。」

他预测AI技术未来的成本会持续下降。尽管目前的推理模型（例如OpenAI 的 o1 模型）需要大量算力和能源消耗，但克里希纳认为，新兴的技术（例如中国初创公司 DeepSeek 展示的方案）能够极大降低AI能耗，使之降到当前能耗的1%以下：

「DeepSeek 已经向我们展示，即使是小型模型也能发挥巨大作用。当然，问题在于我们是否仍需要一些巨大的模型作为起点，这是 DeepSeek 尚未谈及的地方。」

然而，虽然克里希纳认为 AI 会变得越来越普遍和廉价，但他并不认为 AI 能真正帮助人类创造全新的知识，这与 Hugging Face 联合创始人托马斯·沃尔夫（Thomas Wolf）近期的一篇文章观点一致。相反，克里希纳认为，量子计算才是加速科学发现的真正关键技术，而这也正是 IBM 长期以来重金投入的领域：

「AI 所做的都是基于已有的知识、文献、图像等去学习，而并非探索未知。我并不相信目前这一代的AI能够真正实现所谓的『通用人工智能』，也就是说，这些AI无法提供完全可靠的、超越爱因斯坦、奥本海默或所有诺贝尔奖得主所能回答的问题。」

值得注意的是，克里希纳的这些言论与 OpenAI CEO 山姆·奥特曼（Sam Altman）的看法截然不同。奥特曼此前曾预测，人类在未来数年内就可能创造出具备超级智能的AI，大幅加速人类创新的速度。

程序员必知的 89 个操作系统核心概念

Sat, 29 Jul 2023 00:00:00 CST

   点击左上方蓝色“    一口Linux”，选择“    设为星标”

第一时间看干货文章
☞【干货】嵌入式驱动工程师学习路线☞【干货】一个可以写到简历的Linux物联网综合项目☞【干货】 Linux嵌入式知识点-思维导图-免费获取☞【干货】我的新书《从零开始学ARM》正式上线

1

来自:Java 建设者

1. 操作系统（Operating System，OS）：是管理计算机硬件与软件资源的系统 软件，同时也是计算机系统的 内核与基石。操作系统需要处理 管理与配置内存、决定系统资源供需的优先次序、控制输入与输出设备、操作网络与管理文件系统等基本事务。操作系统也提供一个让用户与系统交互的操作界面。

2. shell：它是一个程序，可从键盘获取命令并将其提供给操作系统以执行。在过去，它是类似 Unix 的系统上唯一可用的用户界面。如今，除了命令行界面（CLI）外，我们还具有图形用户界面（GUI）。

3. GUI (Graphical User Interface)：是一种 用户界面，允许用户通过图形图标和音频指示符与电子设备进行交互。

4. 内核模式(kernel mode): 通常也被称为 超级模式（supervisor mode），在内核模式下，正在执行的代码具有对底层硬件的完整且不受限制的访问。它可以执行任何 CPU 指令并引用任何内存地址。内核模式通常保留给操作系统的最低级别，最受信任的功能。内核模式下的崩溃是灾难性的；他们将停止整个计算机。超级用户模式是计算机开机时选择的自动模式。

5. 用户模式(user node)：当操作系统运行用户应用程序（例如处理文本编辑器）时，系统处于用户模式。当应用程序请求操作系统的帮助或发生中断或系统调用时，就会发生从用户模式到内核模式的转换。在用户模式下，模式位设置为 1。从用户模式切换到内核模式时，它从 1 更改为 0。

6. 计算机架构(computer architecture)：在计算机工程中，计算机体系结构是描述计算机系统功能，组织和实现的一组规则和方法。它主要包括指令集、内存管理、I/O 和总线结构

7. SATA(Serial ATA)：串行 ATA (Serial Advanced Technology Attachment)，它是一种电脑总线，负责主板和大容量存储设备（如硬盘及光盘驱动器）之间的数据传输，主要用于个人电脑。

8. 复用(multiplexing)：也称为共享，在操作系统中主要指示了时间和空间的管理。对资源进行复用时，不同的程序或用户轮流使用它。他们中的第一个开始使用资源，然后再使用另一个，依此类推。

9. 大型机(mainframes)：大型机是一类计算机，通常以其大尺寸，存储量，处理能力和高度的可靠性而著称。它们主要由大型组织用于需要大量数据处理的关键任务应用程序。

10. 批处理(batch system): 批处理操作系统的用户不直接与计算机进行交互。每个用户都在打孔卡等脱机设备上准备工作，并将其提交给计算机操作员。为了加快处理速度，将具有类似需求的作业一起批处理并成组运行。程序员将程序留给操作员，然后操作员将具有类似要求的程序分批处理。

11. OS/360：OS/360，正式称为 IBM System / 360 操作系统，是由 IBM 为 1964 年发布的其当时新的 System/360 大型机开发的已停产的批处理操作系统。

12. 多处理系统(Computer multitasking)：是指计算机同时运行多个程序的能力。多任务的一般方法是运行第一个程序的一段代码，保存工作环境；再运行第二个程序的一段代码，保存环境；…… 恢复第一个程序的工作环境，执行第一个程序的下一段代码。

13. 分时系统(Time-sharing)：在计算中，分时是通过多程序和多任务同时在许多用户之间共享计算资源的一种系统

14. 相容分时系统(Compatible Time-Sharing System)：最早的分时操作系统，由美国麻省理工学院计算机中心设计与实作。

15. 云计算(cloud computing)：云计算是计算机系统资源（尤其是数据存储和计算能力）的按需可用性，而无需用户直接进行主动管理。这个术语通常用于描述 Internet 上可供许多用户使用的数据中心。如今占主导地位的大型云通常具有从中央服务器分布在多个位置的功能。如果与用户的连接相对较近，则可以将其指定为边缘服务器。

16. UNIX 操作系统：UNIX 操作系统，是一个强大的多用户、多任务操作系统，支持多种处理器架构，按照操作系统的分类，属于分时操作系统。

17. UNIX System V：是 UNIX 操作系统的一个分支。

18. BSD(Berkeley Software Distribution)：UNIX 的衍生系统。

19. POSIX：可移植操作系统接口，是 IEEE 为要在各种 UNIX 操作系统上运行软件，而定义 API 的一系列互相关联的标准的总称。

20. MINIX：Minix，是一个迷你版本的类 UNIX 操作系统。

21. Linux：终于到了大名鼎鼎的 Linux 操作系统了，太强大了，不予以解释了，大家都懂。

22. DOS (Disk Operating System)：磁盘操作系统（缩写为 DOS）是可以使用磁盘存储设备（例如软盘，硬盘驱动器或光盘）的计算机操作系统。

23. MS-DOS(MicroSoft Disk Operating System)：一个由美国微软公司发展的操作系统，运行在 Intel x86 个人电脑上。它是 DOS 操作系统家族中最著名的一个，在 Windows 95 以前，DOS 是 IBM PC 及兼容机中的最基本配备，而 MS-DOS 则是个人电脑中最普遍使用的 DOS 操作系统。

24. MacOS X，怎能少的了苹果操作系统？macOS 是苹果公司推出的基于图形用户界面操作系统，为 Macintosh 的主操作系统

25. Windows NT(Windows New Technology)：是美国微软公司 1993 年推出的纯 32 位操作系统核心。

26. Service Pack(SP)：是程序的更新、修复和（或）增强的集合，以一个独立的安装包的形式发布。许多公司，如微软或 Autodesk，通常在为某一程序而做的修补程序达到一定数量时，就发布一个 Service Pack。

27. 数字版权管理（DRM）：他是工具或技术保护措施（TPM）是一组访问控制技术，用于限制对专有硬件和受版权保护的作品的使用。

28. x86：x86 是一整套指令集体系结构，由 Intel 最初基于 Intel 8086 微处理器及其 8088 变体开发。采用内存分段作为解决方案，用于处理比普通 16 位地址可以覆盖的更多内存。32 位是 x86 默认的位数，除此之外，还有一个 x86-64 位，是 x86 架构的 64 位拓展，向后兼容于 16 位及 32 位的 x86 架构。

29. FreeBSD：FreeBSD 是一个类 UNIX 的操作系统，也是 FreeBSD 项目的发展成果。

30. X Window System：X 窗口系统（X11，或简称 X）是用于位图显示的窗口系统，在类 UNIX 操作系统上很常见。

31. Gnome：GNOME 是一个完全由自由软件组成的桌面环境。它的目标操作系统是 Linux，但是大部分的 BSD 系统亦支持 GNOME。

32. 网络操作系统(network operating systems)：网络操作系统是用于网络设备（如路由器，交换机或防火墙）的专用操作系统。

33. 分布式网络系统(distributed operating systems)：分布式操作系统是在独立，网络，通信和物理上独立计算节点的集合上的软件。它们处理由多个 CPU 服务的作业。每个单独的节点都拥有全局集合操作系统的特定软件的一部分。

34. 程序计数器(Program counter)：程序计数器是一个 CPU 中的 寄存器，用于指示计算机在其程序序列中的 位置。

35. 堆栈寄存器(stack pointer)：堆栈寄存器是计算机 CPU 中的寄存器，其目的是 跟踪调用堆栈。

36. 程序状态字(Program Status Word): 它是由操作系统维护的 8 个字节（或 64 位）长的数据的集合。它跟踪系统的当前状态。

37. 流水线(Pipeline): 在计算世界中，管道是一组串联连接的数据处理元素，其中一个元素的输出是下一个元素的输入。流水线的元素通常以并行或按时间分割的方式执行。通常在元素之间插入一定数量的缓冲区存储。

38. 超标量(superscalar)：超标量 CPU 架构是指在一颗处理器内核中实行了指令级并发的一类并发运算。这种技术能够在相同的 CPU 主频下实现更高的 CPU 流量。

39. 系统调用(system call): 指运行在用户空间的程序向操作系统内核请求需要更高权限运行的服务。系统调用提供用户程序与操作系统之间的接口。大多数系统交互式操作需求在内核态运行。如设备 IO 操作或者进程间通信。

40. 多线程(multithreading)：是指从软件或者硬件上实现多个线程并发执行的技术。具有多线程能力的计算机因为有硬件支持而能够在同一时间执行多个线程，进而提升整体处理性能。

41. CPU 核心(core)：它是 CPU 的大脑，它接收指令，并执行计算或运算以满足这些指令。一个 CPU 可以有多个内核。

42. 图形处理器(Graphics Processing Unit)：又称显示核心、视觉处理器、显示芯片或绘图芯片；它是一种专门在个人电脑、工作站、游戏机和一些移动设备（如平板电脑、智能手机等）上运行绘图运算工作的微处理器。

存储体系结构：顶层的存储器速度最高，但是容量最小，成本非常高，层级结构越向下，其访问效率越慢，容量越大，但是造价也就越便宜。

44. 高速缓存行(cache lines)：其实就是把高速缓存分割成了固定大小的块，其大小是以突发读或者突发写周期的大小为基础的。

45. 缓存命中(cache hit)：当应用程序或软件请求数据时，会首先发生缓存命中。首先，中央处理单元（CPU）在其最近的内存位置（通常是主缓存）中查找数据。如果在缓存中找到请求的数据，则将其视为缓存命中。

46. L1 cache：一级缓存是 CPU 芯片中内置的存储库。L1 缓存也称为 主缓存，是计算机中 最快的内存，并且最接近处理器。

47. L2 cache: 二级缓存存储库，内置在 CPU 芯片中，包装在同一模块中，或者建在主板上。L2 高速缓存提供给 L1 高速缓存，后者提供给处理器。L2 内存比 L1 内存慢。

48. L2 cache: 三级缓存内置在主板上或 CPU 模块内的存储库。L3 高速缓存为 L2 高速缓存提供数据，其内存通常比 L2 内存慢，但比主内存快。L3 高速缓存提供给 L2 高速缓存，后者又提供给 L1 高速缓存，后者又提供给处理器。

49. RAM((Random Access Memory)：随机存取存储器，也叫主存，是与 CPU 直接交换数据的内部存储器。它可以随时读写，而且速度很快，通常作为操作系统或其他正在运行中的程序的 临时数据存储介质。RAM 工作时可以随时从任何一个指定的地址写入（存入）或读出（取出）信息。它与 ROM 的最大区别是数据的 易失性，即一旦断电所存储的数据将随之丢失。RAM 在计算机和数字系统中用来暂时存储程序、数据和中间结果。

50. ROM (Read Only Memory)：只读存储器是一种半导体存储器，其特性是 一旦存储数据就无法改变或删除，且内容不会因为电源关闭而 消失。在电子或电脑系统中，通常用以存储不需经常变更的程序或数据。

51. EEPROM (Electrically Erasable PROM)：电可擦除可编程只读存储器，是一种可以通过电子方式多次复写的半导体存储设备。

52. 闪存(flash memory)：是一种电子式可清除程序化只读存储器的形式，允许在操作中被多次擦或写的存储器。这种科技主要用于一般性数据存储，以及在电脑与其他数字产品间交换传输数据，如储存卡与 U 盘。

53. SSD(Solid State Disks)：固态硬盘，是一种主要以闪存作为永久性存储器的电脑存储设备。

54. 虚拟地址(virtual memory)：虚拟内存是计算机系统 内存管理的一种机制。它使得应用程序认为它拥有连续可用的内存（一个连续完整的地址空间），而实际上，它通常是被分隔成多个物理内存碎片，还有部分暂时存储在外部磁盘存储器上，在需要时进行数据交换。与没有使用虚拟内存技术的系统相比，使用这种技术的系统使得大型程序的编写变得更容易，对真正的物理内存（例如 RAM）的使用也更有效率。

55. MMU (Memory Management Unit)：内存管理单元，有时称作分页内存管理单元。它是一种负责处理中央处理器（CPU）的内存访问请求的计算机硬件。它的功能包括 虚拟地址到物理地址的转换（即虚拟内存管理）、内存保护、中央处理器高速缓存的控制等。

56. context switch：上下文切换，又称环境切换。是一个存储和重建 CPU 状态的机制。要交换 CPU 上的进程时，必需先行存储当前进程的状态，然后再将进程状态读回 CPU 中。

57. 驱动程序(device driver)：设备驱动程序，简称驱动程序（driver），是一个允许高级别电脑软件与硬件交互的程序，这种程序创建了一个硬件与硬件，或硬件与软件沟通的接口，经由主板上的总线或其它沟通子系统与硬件形成连接的机制，这样使得硬件设备上的数据交换成为可能。

58. 忙等(busy waiting)：在软件工程中，忙碌等待 也称自旋，是一种以进程反复检查一个条件是否为真的条件，这种机制可能为检查键盘输入或某个锁是否可用。

59. 中断(Interrupt)：通常，在接收到来自外围硬件（相对于中央处理器和内存）的异步信号，或来自软件的同步信号之后，处理器将会进行相应的硬件／软件处理。发出这样的信号称为进行 中断请求（interrupt request，IRQ）。硬件中断导致处理器通过一个 运行信息切换（context switch）来保存执行状态（以程序计数器和程序状态字等寄存器信息为主）； 软件中断则通常作为 CPU 指令集中的一个指令，以可编程的方式直接指示这种运行信息切换，并将处理导向一段中断处理代码。中断在计算机多任务处理，尤其是即时系统中尤为有用。

60. 中断向量(interrupt vector)：中断向量位于中断向量表中。 中断向量表（IVT）是将中断处理程序列表与中断向量表中的中断请求列表相关联的数据结构。中断向量表的每个条目（称为中断向量）都是中断处理程序的地址。

61. DMA (Direct Memory Access)：直接内存访问，直接内存访问是计算机科学中的一种内存访问技术。它允许某些电脑内部的硬件子系统（电脑外设），可以独立地直接读写系统内存，而不需中央处理器（CPU）介入处理。

62. 总线(Bus)：总线（Bus）是指计算机组件间规范化的交换数据的方式，即以一种通用的方式为各组件提供数据传送和控制逻辑。

63. PCIe (Peripheral Component Interconnect Express)：官方简称 PCIe，是计算机总线的一个重要分支，它沿用现有的 PCI 编程概念及信号标准，并且构建了更加高速的串行通信系统标准。

64. DMI (Direct Media Interface)：直接媒体接口，是英特尔专用的总线，用于电脑主板上南桥芯片和北桥芯片之间的连接。

65. USB(Universal Serial Bus)：是连接计算机系统与外部设备的一种 串口总线标准，也是一种输入输出接口的技术规范，被广泛地应用于个人电脑和移动设备等信息通讯产品，并扩展至摄影器材、数字电视（机顶盒）、游戏机等其它相关领域。

66. BIOS(Basic Input Output System)：是在通电引导阶段运行硬件初始化，以及为操作系统提供运行时服务的固件。它是开机时运行的第一个软件。

67. 硬实时系统(hard real-time system)：硬实时性意味着你必须绝对在每个截止日期前完成任务。很少有系统有此要求。例如核系统，一些医疗应用（例如起搏器），大量国防应用，航空电子设备等。

68. 软实时系统(soft real-time system)：软实时系统可能会错过某些截止日期，但是如果错过太多，最终性能将下降。一个很好的例子是计算机中的声音系统。

69. 进程(Process)：程序本身只是指令、数据及其组织形式的描述，进程才是程序（那些指令和数据）的真正运行实例。若进程有可能与同一个程序相关系，且每个进程皆可以同步（循序）或异步的方式独立运行。

70. 地址空间(address space)：地址空间是内存中可供程序或进程使用的有效地址范围。也就是说，它是程序或进程可以访问的内存。存储器可以是物理的也可以是虚拟的，用于执行指令和存储数据。

71. 进程表(process table)：进程表是操作系统维护的 数据结构，该表中的每个条目（通常称为上下文块）均包含有关 进程的信息，例如进程名称和状态，优先级，寄存器以及它可能正在等待的信号灯。

72. 命令行界面(command-line interpreter)：是在图形用户界面得到普及之前使用最为广泛的用户界面，它通常不支持鼠标，用户通过键盘输入指令，计算机接收到指令后，予以执行。

73. 进程间通信(interprocess communication)：指至少两个进程或线程间传送数据或信号的一些技术或方法。

74. 超级用户(superuser)：也被称为管理员帐户，在计算机操作系统领域中指一种用于进行系统管理的特殊用户，其在系统中的实际名称也因系统而异，如 root、administrator 与 supervisor。

75. 目录(directory): 在计算机或相关设备中，一个目录或文件夹就是一个装有数字文件系统的虚拟 容器。在它里面保存着一组文件和其它一些目录。

76. 路径(path name)：路径是一种电脑文件或目录的名称的通用表现形式，它指向文件系统上的一个唯一位置。

77. 根目录(root directory)：根目录指的就是计算机系统中的顶层目录，比如 Windows 中的 C 盘和 D 盘，Linux 中的 /。

78. 工作目录(Working directory)：它是一个计算机用语。用户在操作系统内所在的目录，用户可在此目录之下，用相对文件名访问文件。

79. 文件描述符(file descriptor)：文件描述符是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。

80. inode：索引节点的缩写，索引节点是 UNIX 系统中包含的信息，其中包含有关每个文件的详细信息，例如节点，所有者，文件，文件位置等。

81. 共享库(shared library)：共享库是一个包含目标代码的文件，执行过程中多个 a.out 文件可能会同时使用该目标代码。

82. DLLs (Dynamic-Link Libraries)：动态链接库，它是微软公司在操作系统中实现 共享函数库概念的一种实现方式。这些库函数的扩展名是 .DLL、.OCX（包含 ActiveX 控制的库）或者. DRV（旧式的系统驱动程序）。

83. 客户端(clients)：客户端是访问服务器提供的服务的计算机硬件或软件。

84. 服务端(servers)：在计算中，服务器是为其他程序或设备提供功能的计算机程序或设备，称为 服务端

85. 主从架构(client-server)：主从式架构也称 客户端/服务器架构、 C/S架构，是一种网络架构，它把客户端与服务器区分开来。每一个客户端软件的实例都可以向一个服务器或应用程序服务器发出请求。有很多不同类型的服务器，例如文件服务器、游戏服务器等。

86. 虚拟机(Virtual Machines)：在计算机科学中的体系结构里，是指一种特殊的软件，可以在计算机平台和终端用户之间创建一种环境，而终端用户则是基于虚拟机这个软件所创建的环境来操作其它软件。

87. Java 虚拟机(Jaav virtual Machines)：Java 虚拟机有自己完善的硬体架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。JVM 屏蔽了与具体操作系统平台相关的信息，使得 Java 程序只需生成在 Java 虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。

88. 目标文件(object file)：目标文件是包含 目标代码的文件，这意味着通常无法直接执行的可重定位格式的机器代码。目标文件有多种格式，相同的目标代码可以打包在不同的目标文件中。目标文件也可以像共享库一样工作。

89. C preprocessor：C 预处理器是 C 语言、C++ 语言的预处理器。用于在编译器处理程序之前预扫描源代码，完成头文件的包含, 宏扩展, 条件编译, 行控制等操作。

end

一口Linux

关注，回复【 1024 】海量Linux资料赠送

精彩文章合集

文章推荐

☞【专辑】 ARM☞【专辑】粉丝问答☞【专辑】 linux入门☞【专辑】计算机网络☞【专辑】 Linux驱动☞【干货】嵌入式驱动工程师学习路线☞【干货】 Linux嵌入式所有知识点-思维导图

程序员延寿指南 | A programmer's guide to live longer

Tue, 11 Jul 2023 09:20:30 CST

1. 术语

ACM: All-Cause Mortality / 全因死亡率

2. 目标

稳健的活得更久
花更少时间工作：见 MetaGPT

3. 关键结果

降低66.67%全因死亡率
增加~20年预期寿命
维持多巴胺于中轴

4. 分析

主要参考：对ACM的学术文献相对较多，可以作为主要参考
增加寿命与ACM关系非线性：显然增加寿命与ACM关系是非线性函数，这里假设 ΔLifeSpan=(1/(1+ΔACM)-1)*10（ΔACM为ACM变化值；公式欢迎优化）
变量无法简单叠加：显然各个变量之间并不符合独立同分布假设，变量之间的实际影响也并不明确
存在矛盾观点：所有的证据都有文献/研究对应，但注意到：有些文献之间有显著矛盾的观点（如对于碳水摄入比例的矛盾）；有些文献存在较大争议（如认为22点前睡觉会提升43%全因死亡率）
研究仅表达相关：所有文献表明的更多是相关而非因果，在阅读时要考虑文献是否充分证明了因果 —— 如某文献表明了日均>=7000步的人有显著低的全因死亡率。但步数少的人可能包含更多长期病患，如果没有合理的排除这块数据，那此文献调查失真

5. 行动

输入
- 固体：吃白肉（-11%~-3% ACM）、蔬果为主（-26%~-17% ACM），多吃辣（-23% ACM），多吃坚果（-27%~-4% ACM），中量碳水、多吃植物蛋白（-10% ACM），少吃超加工食物（-62%~-18%）
- 液体：喝咖啡（-22%~-12% ACM），喝牛奶（-17%~-10% ACM），喝茶（-15%~-8% ACM），少喝或不喝甜味饮料（否则每天一杯+7% ACM，+多巴胺），戒酒或每周100g（纯酒精量(g)=饮酒量(ml)×酒精浓度(%)×酒精密度0.8g/ml）内（否则+~50% ACM，无上限）
- 气体：不吸烟（否则+~50% ACM，-12~-11年寿命）
- 光照：晒太阳（-~40% ACM）
- 药物：二甲双胍（糖尿病人相比正常人可以+3年）、复合维生素（-8%癌症风险）、亚精胺（-60%~-30% ACM）、葡萄糖胺（-39% ACM）
输出
- 运动：每周3次45分钟挥拍运动（-47% ACM）
- 日常：刷牙（-25% ACM）
- 睡眠：每天睡7小时全因死亡率最低；且22-24点间最好， 早睡+43% ACM，晚睡+15% ACM（存在争议）
上下文
- 体重：减肥（-54% ACM）

6. 证据

6.1. 输入

6.1.1. 固体

白肉
- JAMA子刊：食用红肉和加工肉类会增加心脏病和死亡风险！鱼肉和家禽肉则不会
  - 出处： Associations of Processed Meat, Unprocessed Red Meat, Poultry, or Fish Intake With Incident Cardiovascular Disease and All-Cause Mortality
  - 增加红肉摄入与死亡风险相关。八年内平均每天增加至少半份红肉摄入（半份红肉相当于14g加工红肉或40g非加工红肉）的调查对象，在接下来八年内全因死亡风险增加10％（HR, 1.10; 95%CI, 1.04-1.17）；每周吃两份红肉或加工肉类（但不包括家禽或鱼类）会使全因死亡风险增加3%
- 红肉和白肉最大的区别是什么？为啥要这么分呢？
蔬果
- 每年54万人死亡，竟是因为水果吃得少！？这已成十大死亡因素之一！
  - 出处： Estimated Global, Regional, and National Cardiovascular Disease Burdens Related to Fruit and Vegetable Consumption: An Analysis from the Global Dietary Database (FS01-01-19)
  - 每天摄入200克新鲜水果可使死亡率降低17%，糖尿病大血管并发症（如中风、缺血性心脏病等）风险降低13%，及糖尿病小血管并发症（如糖尿病肾病、糖尿病眼病、糖尿病足病等）风险降低28%
- 《自然》子刊：每天二两西兰花，健康长寿都有啦！分析近6万人23年的数据发现，吃含黄酮类食物与死亡风险降低20%相关丨临床大发现
  - 出处： Flavonoid intake is associated with lower mortality in the Danish Diet Cancer and Health Cohort
  - 吃含黄酮类食物与死亡风险降低20%相关
  - Bondonno博士说道“吃不同蔬菜、水果补充，不同种类的黄酮类化合物是很重要的，这很容易通过饮食实现：一杯茶、一个苹果、一个橘子、100克蓝莓，或100克西兰花，就能提供各种黄酮类化合物，并且总含量超过500毫克。
辣椒
- 辣椒成死亡克星？据调研，常吃辣患病死亡风险可降低61%
  - 出处1： Chili pepper consumption and mortality in Italian adults
  - 出处2： The Association of Hot Red Chili Pepper Consumption and Mortality: A Large Population-Based Cohort Study
  - 2017年Plos One 的另一项来自美国的研究以16179名，年龄在18岁以上的人群为对象，并对其进行了高达19年的随访，发现在4946例死亡患者中，食用辣椒的参与者的全因死亡率为21.6％，而未食用辣椒的参与者的全因死亡率为33.6％。相较于不吃辣或很少吃（少于每周两次）的人群，每周吃辣＞4次的人群总死亡风险降低23%，心血管死亡风险降低34%。
鸡蛋
- 每天多吃半个蛋，增加7%的全因和心血管死亡风险？
  - 出处： NIH-AARP工作主页、 Egg and cholesterol consumption and mortality from cardiovascular and different causes in the United States: A population-based cohort study
  - 每天多吃半个蛋，增加7%的全因和心血管死亡风险？在假设性替代分析中，研究者发现，用等量的蛋清/鸡蛋替代物、家禽、鱼、乳制品、坚果和豆类分别替代半只全蛋（25克/天）可以降低6%、8%、9%、7%、13%和10%的全因死亡率。 * 鸡蛋
坚果
- 哈佛20年研究：吃核桃的人更长寿，显著减少全因死亡，延长寿命
  - 出处： Association of Walnut Consumption with Total and Cause-Specific Mortality and Life Expectancy in US Adults
  - 通过分析发现，经常食用核桃可以延长寿命，降低心血管疾病死亡风险。比起不吃核桃，每周食用核桃5份以上（1份28克）的健康预期寿命延长1.3岁，全因死亡风险降低14%，心血管疾病死亡率降低25%。
- 研究：每日食生坚果，死亡率降20%
  - 出处1： Association of nut consumption with total and cause-specific mortality
  - 出处2： APG_Health-&-Nutrition-Research-Brochure_DEC-19-18
  - 研究人员发现，每周吃树坚果低于1盎司份量的人，死亡率降低7％。而每周吃了1盎司份量的人，减少11％的死亡率；每周吃2份量的人，减低13％；每周5至6份量者，减少了15％；一周7份以上的人，死亡率则减少20％。
  - 另外两篇发表在《公共科学图书馆在线期刊》(Public Library of Science Online Journal)和《生物医学中心》(BioMed Central)上的医学预科研究论文，展示了试验开始时的横断面数据。这两项研究都评估了7,216名对象，以及他们食用坚果的频率和数量之间的关系。那些每周食用三份以上坚果(包括开心果)的研究对象的死亡率降低39%。
钠（存有大量争议）
- Eur Heart J：钠摄入量与预期寿命、全因死亡率的关系
  - 出处： Messerli F H, Hofstetter L, Syrogiannouli L, et al. Sodium intake, life expectancy, and all-cause mortality[J]. European heart journal, 2021, 42(21): 2103-2112.
  - 在该分析所包含的181个国家中，研究人员发现钠摄入量与出生时的健康预期寿命（β=2.6年/克每日钠摄入量，R2=0.66，P<0.001）和60岁时的健康预期寿命（β=0.3年/克每日钠摄入量，R2=0.60，P=0.048）之间存在正相关关系，但与非传染性疾病死亡（β=17次事件/克每日钠摄入量，R2=0.43，P=0.100）无关。相反，全因死亡率与钠摄入量成负相关（β=−131次事件/克每日钠摄入量，R2=0.60，P<0.001）。在仅限于46个收入最高国家的敏感性分析中，钠摄入量与出生时的健康预期寿命呈正相关（β=3.4年/克每日钠摄入量，R2=0.53，P<0.001），而与全因死亡率（β=−168次事件/克每日钠摄入量，R2=0.50，P<0.001）呈负相关。
  - 该（大范围）研究认为更多的钠摄入与显著更低的全因死亡率有关
  - 针对该论文的延伸解读和讨论：A Fresh Foray in the Salt Wars: Life Expectancy Higher With Greater Sodium Intake
- NEJM/Lancet：不要吃太多盐，中国饮食所致心血管病和癌症死亡全球第一，吃低钠盐可降低全因死亡率
  - 但也有多项研究认为用低钠盐可以降低一系列疾病的发生概率，对全因死亡率的减少有积极影响
碳水（存有大量争议）
- 低碳生酮饮食（四）碳水化合物与长期死亡率
  - 出处：The Lancet Public Health - Dietary carbohydrate intake and mortality: a prospective cohort study and meta-analysis
  - 碳水越低，寿命越短；碳水越高，寿命也轻微缩短；碳水50%左右（其实按照一般的说法，这也算高碳水）是最长寿命区间
- 最强营养搭配！BMJ：这么吃，心血管疾病和死亡风险更低
槟榔
- 如何看待槟榔嚼出来的癌症？槟榔致癌风险究竟有多大？ - 丁香医生的回答 - 知乎
  - 出处：Chewing Betel Quid and the Risk of Metabolic Disease, Cardiovascular Disease, and All-Cause Mortality: A Meta-Analysis( https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0070679)
  - 嚼槟榔会增加21%的全因死亡率
热量限制
- 怎么看待BBC《进食、断食与长寿》？
  - 限制卡路里动物实验：CR（热量限制，即少吃）延迟了恒河猴的多种疾病发病和死亡率，与CR动物相比，正常喂养的猴子的各种疾病患病风险增加2.9倍，死亡风险增加3.0倍。
综合
- 最强营养搭配！BMJ：这么吃，心血管疾病和死亡风险更低
- Associations of fat and carbohydrate intake with cardiovascular disease and mortality: prospective cohort study of UK Biobank participants
  - 通过对这些参与者的数据进行分析，研究人员发现碳水化合物（糖、淀粉和纤维）和蛋白质的摄入与全因死亡率呈非线性关系，而脂肪则与全因死亡率呈线性相关。其中，较高的糖分摄入与全因死亡风险和患心血管疾病的风险较高均有关联，而较高的饱和脂肪酸摄入与全因死亡风险较高有关。
  - 图1：各种营养元素与全因死亡之间的关系
  - 图2：各种营养元素与心血管疾病之间的关系
  - 进一步研究表明，在所有的饮食模式中，全因死亡率风险最低的饮食方式为：10-30g高纤维、14-30%蛋白质、10-25%单不饱和脂肪酸、5%-7%多不饱和脂肪酸以及20%-30%淀粉摄入。
  - 最优能量来源配比：<24%淀粉，15%-17%蛋白质，>15%单不饱和脂肪酸，<15%糖，6%饱和脂肪酸，6%多不饱和脂肪酸，30g+高纤维
- BMJ | 常吃薯片汉堡巧克力等食品，平均死亡年龄仅仅为58岁，死亡风险剧增

6.1.2. 液体

牛奶
- 《柳叶刀》调研21个国家13万人：每天1斤牛奶或酸奶，心血管死亡风险下降23%
- 出处： Association of dairy intake with cardiovascular disease and mortality in 21 countries from five continents (PURE): a prospective cohort study
- 与不食用乳制品的人相比，每天摄入两份乳制品（一份指244克牛奶/酸奶，15克奶酪或5克黄油）的人，全因死亡风险下降了17%，心血管死亡风险下降23%，中风风险下降33%
茶
- 10万中国人随访7年发现，每周喝三次茶与全因死亡风险降低15%，预期寿命增加1.26年相关
- 出处： Tea consumption and the risk of atherosclerotic cardiovascular disease and all-cause mortality: The China-PAR project
- 中国成年人饮茶与死亡风险的前瞻性关联研究
- 纳入分析的438 443例研究对象随访11.1年共发生死亡34 661例。与从不饮茶者相比，当前非每日饮茶者和每日饮茶者全因死亡HR值（95%CI）依次为0.89（0.86-0.91）和0.92（0.88-0.95）。分性别分析显示，饮茶对全因死亡风险的保护作用主要见于男性（交互P<0.05）
无糖（甜味）饮料
- 「无糖饮料使死亡风险增加 26 %」，是真的吗？
  - 相比于软饮料摄入量＜1杯/月的参与者，混合软饮料摄入≥1杯/天的参与者死亡风险增加18%，而摄入含糖软饮料或无糖软饮料会令死亡风险分别增加11%和27%。
- Association Between Soft Drink Consumption and Mortality in 10 European Countries
有糖饮料
- 可乐和奶茶，增加全因死亡率高达62%！果汁降低免疫力，影响肝代谢！含糖饮料那些事
  - 每天1杯含糖饮料增加7%全因死亡率，2杯21%
  - 在34年的随访中，研究人员发现，相比那些一个月喝1杯或者更少含糖饮料的人，每天喝2杯的人总体死亡风险升高了21%，心血管疾病死亡风险升高了31%，癌症死亡风险上升了16%。
  - 只要每天多喝一杯含糖饮料，总体死亡风险将增加7%，心血管疾病的风险将增加10%，癌症相关的死亡风险将16%。
  - 发表在国际顶级期刊《BMJ》上的一篇论文就证明了含糖饮料会在增加患癌风险，当然这篇文章验证的不仅仅是果汁，奶茶也有份——和含糖饮料相关的总体患癌风险要高出通常值18%，100%的鲜榨果汁也会使得整体的患癌风险上升12%。
果汁
- JAMA子刊：100%纯果汁可能比含糖饮料更危险
  - 每天多摄入一份12盎司的含糖饮料，全因死亡率风险增加11%；
  - 每天多摄入一份12盎司的果汁，全因死亡率风险增加24%。
咖啡
- 重磅！多篇研究证实喝咖啡与人群全因死亡率降低直接相关
- 科普 | 喝咖啡又多了一个新理由：降低死亡率！
- 地中海成年人咖啡消耗量及全因，心血管疾病和癌症的死亡率
  - 在最近的荟萃分析中，该研究包括来自不同国家的40项研究和3,852,651名受试者。在这项荟萃分析显示，咖啡摄入量与各种原因的死亡率，CVD和癌症死亡率之间存在非线性关系，每天摄入两杯咖啡的癌症死亡率最低(RR = 0.96)，CVD最低的死亡率，每天2.5杯(RR= 0.83)，全天最低死亡率为每天3.5杯(RR= 0.85)，并且随着咖啡消费量的增加，死亡率没有进一步降低或增加
亚精胺
- Science：科学背书！从精液中发现的亚精胺，竟然有着抗衰老、抗癌、保护心血管和神经、改善肥胖和2型糖尿病等逆天神效
- 饮食中亚精胺摄入量高会降低死亡率

6.1.3. 气体

吸烟
- 即使是低强度吸烟，也增加死亡风险！
  - 研究发现：在42 416名男性和86 735名女性（年龄在35-89岁之间，以前没有患病）中，18 985名男性（45%）和18 072名女性（21%）目前吸烟，其中33%的男性吸烟者和39%的女性吸烟者并不每天吸烟。8866名男性（21%）和53 912名女性（62%）从不吸烟。在随访期间，与从不吸烟相比，每天<10支烟或每天≥10支烟的全因死亡率危险比分别为1.17（95%置信区间1.10-1.25）和1.54（1.42-1.67）。无论年龄或性别，危险比相似。与每日吸烟关系最密切的疾病是呼吸道癌症、慢性阻塞性肺病和胃肠道及血管疾病。在招募时已经戒烟的人的死亡率低于现在每天吸烟者。
  - 吸烟者平均减少寿命11-12年
- 吸烟让人过瘾是什么原理？有节制的吸烟依旧有害吗？

6.1.4. 光照

晒太阳
- 晒太阳和死亡率的关系，如何科学，安全的晒太阳？
  - 丹麦一项长达26年的研究发现，多晒太阳能显著延长寿命，即使是由于过度暴晒诱发皮肤癌的患者，平均寿命也比普通人长了6岁。

6.1.5. 药物

NMN
二甲双胍
- “胍”吹必看丨我就是神药——二甲双胍
  - 二甲双胍不仅在多种肿瘤、心血管疾病及糖尿病中发挥保护作用，而且在肥胖、肝病、肾病及衰老方面也大放异彩。
- 二甲双胍2020最值得了解的“吃瓜”大新闻——护胃、健脑、抗衰、防癌还是致癌？
- 二甲双胍真的那么神吗？美研究：父亲服用二甲双胍或致子女有缺陷
- 不良反应
  - 作为一种使用近百年的药物，二甲双胍的不良反应已经非常明确，常见的有：维生素B12缺乏（7%-17.4%），胃肠道不良反应（最高53%），疲倦（9%），头痛（6%）；严重但不常见的不良反应包括乳酸酸中毒、肝损伤；也有研究表明可能对胎儿致畸
复合维生素
- 服用复合维生素可降低癌症危险8%，其他效果并不显著
葡萄糖胺
- 神奇！氨糖降低心血管死亡率65%，与定期运动效果相当
- 美国西弗吉尼亚大学最新研究发现氨糖（软骨素）可以降低心血管死亡率65%，降低总体死亡率39%，效果与坚持定期运动相对
- 该研究使用1999年至2010年，16,686名成年人的国家健康和营养检查(NHANES)数据，参与者的中位追踪时间为107个月，而其中有648位参与者定期且每服用日500-1000毫克的葡萄糖胺/软骨素一年以上。
亚精胺
- Science：科学背书！从精液中发现的亚精胺，竟然有着抗衰老、抗癌、保护心血管和神经、改善肥胖和2型糖尿病等逆天神效
- 亚精胺是最容易从人体肠道吸收的多胺。许多的食物中都含有大量的亚精胺，例如新鲜的青椒、小麦胚芽、花椰菜、西兰花、蘑菇和各种奶酪，尤其在纳豆等大豆制品、香菇和榴莲中含量更高。在本实验中，研究人员选择了829位年龄在45-84岁之间的参与者进行了为期20年的随访，分析了饮食中亚精胺摄入量与人类死亡率之间的潜在关联。
- 研究发现，女性的亚精胺摄入量高于男性，并且摄入量都会随着年龄的增长而下降。亚精胺的主要来源是全谷物（占13.4%）、苹果和梨（占13.3%）、沙拉（占9.8%）、芽菜（占7.3%）和马铃薯（占6.4%）。研究根据亚精胺摄入量将人群分为三组，低摄入量组（<62.2 µmol / d）、中摄入量组（62.2–79.8 µmol / d）和高摄入量组（> 79.8 µmol / d）。随访期间共记录了341例死亡，其中血管疾病137例，癌症94例，其他原因110例。经计算低中高三组的粗略死亡率分别为40.5%、23.7%和15.1%，这些数据表明亚精胺摄入量与全因死亡率之间的负相关关系显著。随着逐步对年龄、性别和热量的比例进行调整，这种相关关系依然显著。
综合
- 《自然》子刊深度综述：如何开发抗衰老药

6.2. 输出

6.2.1. 挥拍运动

哪种运动性价比最高？权威医学杂志“柳叶刀”给出答案了
- 一周三次，每次45-60分钟，挥拍运动，降低~47%全因死亡率
- 羽毛球、乒乓球、网球等都算挥拍运动，但由于西化研究背景，可能指网球更多。这隐式的表达了全身锻炼更为重要

6.2.2. 剧烈运动

新研究：每天剧烈运动8分钟，可降低全因死亡和心脏病风险
- 每周15-20分钟的剧烈运动，降低16-40%的全因死亡率，剧烈运动时间达到50-57分钟/周，可以进一步降低全因死亡率。这些发现表明，通过在一周的短时间内累积相对少量的剧烈运动可以降低健康风险。

6.2.3. 走路

走路降低全因死亡率超过50%！每天走多少步最合适？《JAMA》子刊超10年研究告诉你答案
- 注1：这项研究参与者的平均年龄为45.2岁
- 注2：平均步数的多少与职业有关，此项研究仅表明相关性，还没有更深度的因果分析

6.2.4. 刷牙

50万国人研究证实：不好好刷牙，致癌！血管疾病也会增多！
- 经常不刷牙的人：癌症、慢性阻塞性肺病及肝硬化风险分别增加了9%、12%和25%，过早死亡风险增加25%。

6.2.5. 泡澡

定期洗澡降低心血管疾病发作风险
- 与每周一至两次泡澡或根本不泡澡相比，每天洗热水澡可以降低28%的心血管疾病总风险，降低26%的中风总风险，脑出血风险下降46%。而浴缸浴的频率与心源性猝死的风险增加无关。

6.2.6. 做家务（老年男性）

Housework Reduces All-Cause and Cancer Mortality in Chinese Men
- 72岁之后男性每周做重型家务可以减少29%平均死亡率
- 重型家务：吸尘、擦地板、拖地、擦洗窗户、洗车、搬动家具、搬煤气罐等等。
- 轻型家务：掸灰尘、洗碗、手洗衣服、熨烫、晾衣服、做饭、买日用品等等。

6.2.7. 睡眠

超30万亚洲人数据：每天睡几个小时最有益长寿？
- 在男性中，与睡眠时长为7小时相比：睡眠持续时间≥10小时与全因死亡风险增加34%相关；
- 在女性中，与睡眠持续时间7小时相比：睡眠持续时间≥10小时与全因死亡风险增加48%相关；
颠覆认知！加拿大研究发现：早睡比熬夜或许更伤身，几点睡才好？
- 其中一个结论为，就寝时间与全因死亡率的关联性强，过早睡觉和过晚睡觉都会影响健康，但是早睡增加的全因死亡率比晚睡增加的死亡率高，早睡增加了43%的死亡风险，而晚睡增加了15%的死亡风险。
- 这项调查研究，还存在很多局限性，比如没有直接证明就寝时间与死亡的关系，仅仅说明相关性，通过参与人群自我报告统计睡眠时间，数据不够客观

6.2.8. 久坐

中国居民膳食指南科学研究报告（2021年）
- 久坐和看电视时间与全因死亡、心血管疾病、癌症和2型糖尿病发病高风险相关，是独立风险因素。久坐时间每天每增加1小时，心血管疾病发生风险增加4%，癌症增加1%，全因死亡风险增加3%。全因死亡和CVD死亡风险增加的久坐时间阈值是6~8h/d，看电视时间阈值是3~4h/d。
世卫组织关于身体活动和久坐行为的指南

6.3. 上下文

6.3.1. 情绪

悲观情绪与更高的全因死亡率和心血管疾病死亡率有关，但乐观情绪并不能起到保护作用
Pessimism is associated with greater all-cause and cardiovascular mortality, but optimism is not protective
- 在1993-1995年间，一项针对50岁以上澳大利亚人健康的双胞胎研究中包括了生活取向测试（LOT），其中包含乐观和悲观的项目。平均20年后，参与者与来自澳大利亚国家死亡指数的死亡信息相匹配。在2,978名具有很多可用分数的参与者中，有1,068人死亡。生存分析测试了各种乐观因素和悲观情绪分数与任何原因，癌症，心血管疾病或其他已知原因的死亡率之间的关联。年龄调整后的悲观量表上的核心与全因和心血管疾病死亡率相关（每1个标准差单位的危险比，95％置信区间和p值1.134、1.065–1.207、8.85×10 –5和1.196、1.045–1.368、0.0093 ），但不会因癌症死亡。乐观得分与悲观得分之间的相关性很弱（年龄调整后的等级相关系数= − 0.176），但与总死亡率或特定原因死亡率没有显着相关性。反向因果关系（引起悲观情绪的疾病）是不可能的，因为在那种情况下，心血管疾病和癌症都会导致悲观情绪。

6.3.2. 贫富

JAMA子刊：贫富差距真能影响寿命？这可能是真的！
- 该研究使用1994-1996年第一次收集的数据，并通过生存模型来分析净资产和长寿之间的关联。结果显示，共收纳5414 名参与者，平均年龄为 46.7岁，包括 2766 名女性。较高的净资产与较低的死亡风险相关。特别是在兄弟姐妹和双胞胎中（n = 2490），在较高的净资产和较低的死亡率之间观察到类似的关联，表明拥有更多财富的兄弟姐妹或双胞胎比拥有更少财富的兄弟姐妹/双胞胎活得更久。

6.3.3. 体重

JAMA子刊：减肥要趁早，才能有效降低死亡率风险
- 对体重减轻的死亡率风险评估发现，体重从肥胖减轻到超重的成年人与稳定肥胖人群相比，全因死亡率降低了54％（危险比为0.46），然而从成年初期的超重减轻到中年以前的正常体重的人群的死亡率风险并未降低（风险比为1.12）。

6.3.4. 新冠

Magnitude, demographics and dynamics of the effect of the first wave of the COVID-19 pandemic on all-cause mortality in 21 industrialized countries
- 目前来看，新冠死亡率（美国）在1.5%左右，人均预期寿命减少了2年
如何看待美国CDC宣称新冠死亡人数被高估？
NVSS deaths

为什么说 AI 无法取代程序员的工作

Mon, 29 May 2023 07:50:39 CST

很多人至今都想不明白为什么我说 AI 无法取代程序员的工作。他们天真地以为，如果有了超级先进的 AI，那么你只要告诉它”需要什么“，它就能给你做出来。然而问题就在于——你怎么告诉它“需要什么”？

“编程”的实质就是告诉电脑“需要什么”。要想让 AI 实现人需要的功能，人必须先告诉它“需要什么”。如果你不能表达”需要什么“，那它怎么可能给你做出来？然而表达“需要什么”这件事，却不是那么容易的，需要长期的学习。

曾经有人天真的以为，只要设计出描述式（descriptive）的语言，就能很容易地表达“需要什么”。他们设计出各种“逻辑式语言”，比如 Prolog，号称这类描述式语言只需要表达“做什么”，而不需要说出具体“怎么做”。然而那些全都失败了。

事实证明，想要表达“需要什么”，无论用什么语言或工具，都不是一件容易的事。如果你不能清晰地表达“需要什么”，连人都没法知道该给你做什么，那机器怎么可能知道？

这就是为什么 AI 永远无法取代程序员，因为它不能直接知道人脑子里想的是什么。除非 AI 有读心术，能直接读出人脑子里想的东西，否则这是不可能的。然而很多人的脑子里是混乱的，他们自己都不知道自己想要什么，就算有读心术都没用。

如果这点逻辑都弄不清楚，那你可能确实是可以被 AI 取代的那种人。[坏笑]

“当你不再是程序员，很多事会脱离掌控”—— 对话全球最大独立开源公司SUSE CTO

Mon, 29 Aug 2022 07:36:07 CST

【CSDN 编者按】作为全球企业级开源解决方案领导者SUSE的CTO，Brent Schroeder见证了一波又一波技术潮流赋能企业创新发展，为企业注入新活力。同时，他也感受到技术革新给企业的商业策略、运营方式和IT基础设施所带来的冲击。他认为，在如今开源和云原生大潮来临的时代，企业需要做好新一轮乘风破浪的准备。

作者 | 宋林飞
出品 |《新程序员》编辑部

1992年，三名来自德国的数学系学生和一名刚毕业不久的软件工程师共同成立了一个UNIX服务小组，这也是SUSE的雏形。两年后，SUSE发布了其首个Linux发行版—SUSE Linux1.0。此后，SUSE与IBM、SAP等头部科技企业逐渐达成合作，并巩固了自身在企业级Linux解决方案供应商中的地位。经过三十年的发展，SUSE已然成为了头部开源技术供应商之一，除了原有的企业级Linux产品外，它还向客户提供Kubernetes管理平台和边缘解决方案，利用团队专业的开源技术帮助企业用户实现业务增长。

作为SUSE的CTO，Brent Schroeder在概括自己的日常工作时说道：“我现在做的事和我作为学生、程序员时本质上没有区别，都是在解决问题，变化的是所解决问题的深度和广度。”他表示，现在往往需要跳出这个时代，预判十至二十年后的技术发展趋势，从而提前布局SUSE的产品和研发方向，在未来持续地为用户提供适应时代的解决方案。在从事技术行业的几十年中，Brent Schroeder见证了互联网兴起、大数据时代，再到如今的开源、云原生发展壮大，一波又一波的技术浪潮不断冲击着企业的商业策略、运营方式。在新技术，新思潮带来的变革中，企业唯有在人才、技术、基础设施等方面提前做好准备，才能更好地抓住机遇，应对不断变化的外部环境。除了技术方面的思考，为SUSE团队提供必要的支持也是他管理工作的核心。回想他从程序员向管理层的转型经历，Brent Schroeder坦诚地说：“当你不再是执行者时，很多事都脱离了你的掌控，这令人沮丧。”他认为软技能的培养对想要从事管理工作的技术人尤为重要。

在本期《新程序员 004》的采访中，Brent Schroeder就程序员向管理层转型所遇到的挑战及企业该如何应对新技术潮流的冲击分享了他的观点。以下是本次访谈的详细内容。

学生时期与代码邂逅

邹欣：20世纪80年代，你在美国爱荷华州立大学攻读计算机和工商管理双学位，那时计算机科学还不像现在这么火热，是什么引起了你对编程的兴趣并决定学习这个专业，直到成为一名技术专家？

Brent Schroeder：决定修双学位是因为我那时就感受到了技术赋能商业运作的潜力。我与编程的渊源可以追溯到高中时的编程课，我在Apple II上开发了一个课表管理程序，帮我在排课表时省去了很多麻烦。尽管最初只是用程序实现一些简单的功能，但在那个纸质文件盛行的年代，编程对效率的提升作用深深吸引了我。

在后来的职业生涯中，我致力于探究解决问题的方式，这个习惯也一直驱动着我。作为一名技术专家，我从事的工作可以概括为理解企业在业务中遇到的挑战，并使用技术方式帮助他们解决那些被认为太困难、太昂贵或太耗时的问题，这是非常令人兴奋的。

邹欣：大学期间你印象最深刻的一个人或一件事是什么？

Brent Schroeder：老实说，选出一件事或一个人还是挺难的，因为实在太多了。美国爱荷华州立大学的计算机科学专业非常有竞争力，历史悠久。第一台数字电子计算机—ABC计算机（Atanasoff-Berry Computer）就是在爱荷华州立大学诞生的。但至今我时常会想起一位离散逻辑学的教授在开学第一天对我们的“挑衅”：“向你右边及左边的同学作自我介绍，因为到期中考试的时候，你们之中将有一个不会再出现在这儿了（因为课程很难）。”

邹欣：你提及，在大学期间你就感受到了技术赋能商业的潜力，那时你是否为自己作出了清晰的职业规划？

Brent Schroeder：在我二十多岁时，其实没有长远的规划和目标，只是单纯地享受解决问题的过程和学习新技术。直到进入职场十年后我才开始规划自己的职业蓝图。我最初给自己定下的目标是成为一名技术部门经理，后来慢慢地开始承担管理责任、熟悉CTO的角色，这对我很有吸引力。

SUSE CTO的“岗位描述”

邹欣：从一名学生，到程序员，再到技术专家、CTO，这一路你的思考方式和对技术的理解一定在不停变化，能否与我们分享在不同阶段它们是如何变化的？

Brent Schroeder：从学生到进入职场至今，我所做的事本质上都是解决问题。但变化的是所解决问题的深度、广度和时效。

当我还是一个程序员时，我关注的是赶紧把代码写好，与客户对接，思考如何满足他们实时的业务需求，多数时间需要我解决的问题都是具象的。我的产出看得见、摸得到，在短期内就可以生效并能马上得到客户反馈。

当我进入管理层后，大部分精力都花在了打破团队隔阂，解决他们的问题。比如给团队提供合适的工具，帮助他们提升培养能力，定位团队中的问题，使他们更好地协同等，所处理的事物越来越多样，我需要去平衡自己可用的时间，并且产出不会在短期有直观效果的成果。

成为CTO之后，我思考问题的眼界和层次有了天翻地覆的变化，需要以超前于现有技术环境一代甚至两代的视野来分析整个技术生态的发展趋势。包括预判哪些技术会出现、哪些会成功、哪些不会向预期的方向发展。并以此为依据，结合目前客户和行业所面临的挑战，使用适当的技术组合来帮助他们提前布局，实现商业目标。

邹欣：的确，当作为一位程序员时，你只需要解决具象的问题，产出马上就能被看到。但当你进入管理层，级别越高，你做的事影响越深远，同时也需要更长的时间才能见效。在适应这种变化的过程中你可曾遇到过挑战？

Brent Schroeder：无论是我自己，还是在帮助其他人从程序员向管理层转型的过程中，我发现最大的挑战是“你不再是执行者”。因为在之前的职业生涯中我们已经习惯参与到项目的具体事宜中，通过自己的产出来推进项目的进程。如此，项目成功与否、质量如何，对我来说完全可控。

当你进入管理层之后一切都变了。规划好方向后，剩下的工作需要依靠团队来完成，我能做的只是给他们权限和支持，不能再切实地控制项目走向。尤其是当项目进展不顺利时，这会使人非常沮丧，你会忍不住地想深入细节，自己动手完成一些工作。但你必须摒弃这种想法，如果你把时间花在项目执行层面，就没时间做你的本职工作，为团队成员提供必要的支持。

所以，在角色的过渡中，个人心理建设很重要。需要认清自己的动力是马上得到别人的认可，还是从更宏观、长远的角度来推动事情的发展。

邹欣：许多学生和年轻技术人都认为只要掌握了过硬的技术，自己就无所不能。但当他们慢慢深入职场，参与到更大的团队中，开始参与管理工作时，除了技术能力外，软实力也开始变得重要。你对此有何见解？你认为想要自己的职业生涯能更好地发展，哪些软实力是不可或缺的？

Brent Schroeder：我认为对于技术人而言，技术实力固然重要，但真正将开发者、管理者和CTO区分开的正是软实力。有很多开发者尽管资历很深，但他们还是宁愿留在一线，因为他们认为软实力的提升对他们是很大的挑战。

对于未来想要参与管理的技术人而言，与人交往的能力往往比技术实力更重要。比如，你所带领的团队中有表现较好的成员，这时你就需要思考如何在工作上给他们挑战从而帮助他们更好地成长，如何通过奖励机制激励他们，如何使他们发挥带头作用从而使整个团队得到提升。同时，你的团队中也会有表现欠佳的成员，你需要给他们适当的引导、培训，鼓励他们，通过管理手段改善他们的表现，使其成为团队的贡献者而不是团队的“拖油瓶”。此外，你的团队可能还需要与其他团队合作，你需要说服他们和你一起为了共同的目标努力。

这些都是作为管理者每天都会遇到的挑战，想要克服这些困难，人际交往能力是不可或缺的。不幸的是，这种能力是从课本上学不到的，只能通过不断地实践来培养。

开源与软件的强强联合

邹欣：前面提到，你初学编程时使用的是闭源的Apple II，但如今的学生学习时刚接触的大多是开源系统。对于这种变化，你怎么看？

Brent Schroeder：我认为这种变化是令人兴奋的。虽然Apple II不是现在意义上的开源系统，但我们也有对其进行修改的权限。记得当时我和几个同学在学校机房的电脑上恶作剧，在命令行中动手脚，这样别人在执行这些命令时系统就会给出奇奇怪怪的反馈，至今想起这些我依然感到非常有趣。如今的学生能够看到底层代码并自由地对其进行修改，这能使编程的学习充满乐趣。

邹欣：在如今的科技产业中，许多企业都在使用开源协作来驱动创新。你认为开源为什么能成为推动科技创新的主要实践？

Brent Schroeder：开源能推动创新是因为它激发了工程师们与同行合作的热情，从而把世界上最优秀的工程师们聚集在一起，通过开放协作的方式共同攻克业内难题。

开源社区是多元化的，这体现在社区成员拥有不同的背景、经验，来自不同的环境。将这些多元化的经验、特点综合在一起，所产生的能力要远远超过公司内部一群身处“与世隔绝”环境中的程序员。通过这种大规模合作，多元化的社区，开源软件才能实现快速的迭代和创新。

邹欣：假如一个项目的参与者越多，项目中的Bug就越容易被发现和修复，质量也会变得越来越好，这无可厚非。但对于企业级开源软件来说，因为它们在企业运作中扮演重要角色，很多企业对于如此开放的软件难免会不信任。那么，该如何解决这些企业用户的担忧？

Brent Schroeder：不可否认的是，我们这些沉浸在开源中的人常常会忽视外行人对开源软件的误解。我上周参加了一个金融行业的专题讨论，很多出席的行业人士都表示了他们对引入开源软件的担忧。

我认为要做好企业级开源解决方案，除了促进开放协作，同时也要关注软件的可控性和社区治理机制来确保产品的质量和安全性，这些是企业用户最关切的。尽管在开源协作中社区的多元性和活跃度非常重要，但开源项目必须要向着既定的方向发展，这就需要社区治理能力，保证社区内的成员都向着同一目标贡献。有许多开源项目都是由于缺乏共同的方向，导致了开发过程中不必要的复杂性和优先级冲突因而越做越差。

因此，要解决企业用户的担忧，可以从以下方面着手：

确认项目目标，使社区成员保持同步。
从开发流程上重视软件的完整度和安全性，手段包括严格的代码审查机制、测试制度，并保证每一次上线都经过此流程。
如果开发中使用到了外部软件，需注意外部软件是否存在漏洞和安全问题。

假如开源开发严格按照完善的流程执行，所产出软件的安全性、可控性会超过闭源软件，因为它从设计到落地得到了无数社区精英的关注。你可以想象假如在闭源公司中要雇佣这么多人来审查代码和进行安全测试成本会有多高！

云原生浪潮下的科技公司

邹欣：除了开源之外，云原生在近几年也异常火热。自云原生概念被首次提出以来，大家对云原生的定义仿佛一直在变化。我们该如何理解这种定义的变化？基于现在的环境和你的理解，你如何定义云原生?

Brent Schroeder：虽然云原生在迅速发展，但我不认为它定义的本质在改变，变化的是在定义范围内我们能实现什么。行业对云原生最初的描述中提及了许多概念，包括DevOps、微服务、敏捷开发、持续交付、公司文化和流程，更多的是过程和结果，而不是特定技术。这代表云原生所使用的技术可以不断发展、变化，以构建可伸缩、有弹性、持续迭代、在云上可靠的应用程序。

在早期，大家还在讨论什么类型的应用与云原生更匹配，但随着云原生产出了越来越多的价值，如今人们希望将它应用到更多的场景中，所以必须开拓新的技术手段。

我对云原生的定义非常简单—它是流程和技术的结合，让企业可以构建和快速迭代应用，使应用具有动态伸缩的能力，赋予基础设施更高的容错率，并可移植到所需的业务领域以满足业务需求—这意味着它可以运行在公有云、私有数据中心中，或广泛分布在各种边缘节点上。

邹欣：云原生如今已成为实现企业数字化转型的技术趋势。在引入云原生之前企业应该有何准备？企业该如何拥抱云原生趋势？

Brent Schroeder：云原生会对企业的技术、人才、商业战略等方面带来冲击，如果企业不做好周全的准备，云原生技术引入会对企业产生负面影响。

引入云原生技术从企业购买云服务开始，因为云原生不会在一夜之间发生。它需要企业加大对IT部门和业务部门所需人员，以及必要技术的投资。

人才方面，从IT运营团队、平台架构师到开发人员，他们必须经过适当的培训，学习云原生开发所需技能。人才投资会大大提高成功的概率和效率。

企业和员工必须熟悉云原生架构下的开发流程，采用以CI/CD开发和交付方法为核心的DevOps文化。

选择合适的技术。容器、Kubernetes、基础设施，通过自动化代码来管理权限管控或安全策略，都是云原生技术概念。

总的来说，企业拥抱云原生首要考虑的应该是思想、策略和人才培养，最后才是技术。虽然大多数云原生基础设施的技术都是开源的，但我们强烈鼓励企业与技术提供商加强合作，借助技术提供商的丰富经验来协助技术引入和项目的生命周期管理。

邹欣：云原生技术正在渗透传统行业，在未来十年，哪些行业受到的云原生影响最大？云原生将如何改变它们?

Brent Schroeder：我认为所有行业都会受到云原生的冲击。如今，每个行业的公司都在变成技术公司。无论是零售、制造、金融、运输、医疗，甚至是政府服务，都面临着向客户提供多样化服务和新功能的挑战。企业必须能够更快地作出反应，来支持多样化的需求，应对变化—而云原生方法和技术可以实现这一点。

前段时间，我与一家石油公司就边缘计算技术进行了沟通，我惊讶地发现他们也将自己定位成一家科技公司。他们认为云原生技术可以提升内部系统对石油基础设施的监控能力，提升其解决和预判问题的效率，使企业运作更平稳、可靠。

邹欣：对于云原生时代的开发者来说，他们必须具备哪些技能才能满足行业的需求?

Brent Schroeder：我认为开发者必须掌握云原生相关的方法论，包括DevOps、CI/CD、微服务等。技术行业的发展目标是尽可能从业务开发中抽象出底层技术，这使得业务开发人员能专注于业务交付，而不是IT基础设施。但对于底层架构工程师来说，他们有更多需要掌握的技能，包括容器、Kubernetes等。

SUSE成功的“秘诀”

邹欣：SUSE的研发团队目前主要关注哪些研究领域?

Brent Schroeder：SUSE是创新、可靠、安全的企业级开源解决方案的全球领导者，超过60%的财富500强企业依赖SUSE来驱动他们的业务。我们专注于企业级Linux、Kubernetes管理平台和边缘解决方案的研发，并与社区合作，使我们的客户能在各个领域创新。

简化和扩展云原生应用是我们研发的重点领域，因为企业对它的需求日渐紧迫。时至今日，云原生开发需要很多专业技能和新技术。为了让更多的企业享受云原生的红利，SUSE专注于简化容器、Kubernetes、边缘计算等企业级解决方案。这些解决方案将在2022年及以后走向企业，帮助他们实现应用程序升级和数据集成。

邹欣：Kubernetes正在成为“一切”的平台，SUSE如何帮助用户更好地融入这个技术潮流？

Brent Schroeder：我想扩展一下此观点—Kubernetes和Linux正在成为一切的平台，Linux作为企业基础设施和操作环境，而Kubernetes被用来编配平台，它们相互配合。SUSE的产品正在为客户提供完整的企业级解决方案。首先，我们有可适配企业用户几乎所有基础设施的企业级Linux操作系统——SUSE Linux Enterprise。然后基于Kubernetes的企业容器管理平台SUSE Rancher—它是业内可扩展性最高、最开放的Kubernetes平台，帮助用户管理分布在多个数据中心、多个云和边缘结点的集群，部署混合和多云架构以解决业务痛点问题。最后，为提升开发人员的生产力和灵活性，SUSE提供Rancher Desktop和SLE BCI(基于容器镜像)。

邹欣：“如何从开源中赚钱”仍然是中国所有开源创业公司所面临的主要问题之一，SUSE有什么经验或建议可以分享?

Brent Schroeder：开源是SUSE的核心，它推动我们与客户合作创新。开源技术的源代码面向所有人开放，因此开源商业化的业务模型是要向客户提供代码之外的增量价值。

SUSE通过提供大量开源项目的发行版来传递这种价值。这使得客户不必成为开源项目的专家，也能专注自身的业务，将人力主要投入在服务客户层面而不用担心基础设施。

这种业务方式的挑战是客户认为他们可以自己构建和支持这些开源项目。这无可厚非，如果有足够的时间和资源，很多企业都可以这样做。但是，我总是会反问考虑这种模式的潜在客户：“你们的业务目标是什么?既然引入开源是为了支持业务或服务客户，为什么不允许专业的开源供应商来为你们部署开源基础设施？”

— 推荐阅读 —

《新程序员001-004》已全面上市

程序员要进入Google、Amazon这样的顶级IT公司，需要达到什么样的技术水平？

Mon, 15 Aug 2022 00:00:00 CST

现在北美求职市场飘忽不定。能不能进入这些公司或毕业就上车，在一定程度上更取决于你的就业时间，而不是你的能力。我当年在USC见过很多水人赶上Amazon扩招直接两轮OA拿Offer的，也有很厉害的大神赶上市场缩招半年没有一个面试，被ICC拒了的。2020年疫情北美缩招，我在国内阿里的一个同学所在的组新招的应届生都是UCLA, UT-Austin，CMU 正统MSCS毕业，在北美没找到工作的。

北美互联网就业远比你想象的更具有不确定性，难度也远比你想象的大的多。身为过来人，我给你们的诚恳并且稳妥一点的建议是。 1.先拿到国内一线互联网公司的Offer在国内攒两三年工作经验。2. 一定要练英语口语，至少达到能不看字幕听懂老友记的水准。3. 申请一个北美两年制的硕士，尽量能在两年内发一篇CCF B类以上的论文，这能证明你在相关的领域达到一定的见解。4. 刷题刷题再刷题，尽量刷到800道以上，并且真正理解。

如果你能达到以上四点，即便遇到就业低峰期，你也是有可能在北美的就业市场分到一杯羹的。否则按照当前的形式，你留学两年的钱很有可能打了水漂。

最后劝各位不要听一些求职公司或者所谓润学人的胡言乱语，这群人的目标根本不是为了帮你就业，而是掏干你口袋里的钱让你报名他们的求职班等等。北美这些一线公司现在的门槛远比他们描述的高的多的多。

程序员必知的分布式容错和降级技术

Sun, 13 Mar 2022 00:00:00 CST

可以参与抽奖

参与方式

关注公众号：35岁程序员那些事，后台回复关键词“参与抽奖”，获取抽奖链接，点击抽奖。中奖之后，可以联系笔者的微信号或者公众号后台回复关键词“联系笔者”，获取联系方式。

分布式容错和降级是微服务架构中应对瞬时大流量的最佳解决方案。

推荐使用Spring Cloud Alibaba+Sentinel

Nginx

Nginx是一块轻量级的Web服务器/反向代理服务器，目前在github上Star 13.3k Fork 4.9k Watch 951，整体关注度也非常高，最近一次更新是2020年12月5日，最新的版本为release-1.19.6。

那么如何使用Nginx进行应用的分布式容错和降级呢？答案就是Nginx+Lua可以实现分布式容错和降级，利用Lua脚本可以实现限流算法，并从应用接入层做容错和降级。

Guava

Guava是一种基于开源的Java库，其中包含谷歌内部使用的很多核心库。这个库是为了方便编码，并减少编码错误。这个库提供了用于集合、缓存、支持原语、并发性、常见注解、字符串处理、I/O等实用方法API，这些都是谷歌开发者结合自身业务场景的最佳实践，可以说是一块非常优秀的开源中间件框架。

Guava - RateLimiter使用的是一种叫令牌桶的流控算法，RateLimiter会按照一定的频率往桶里扔令牌，线程拿到令牌才能执行。

Guava目前在github上Star 40k Fork 8.9k Watch 2.5k，最近一次更新是2020年12月15日，最新版本为30.1，无论是开源的关注度和活跃度都非常高。

Redis

Redis是互联网技术领域使用最为广泛的存储中间件，它是“Remote Dictionary Service”（远程字典服务）的首字母缩写。Redis以其超高的性能、完美的文档、简洁易懂的源码和丰富的客户端库支持在开源中间件领域广受好评。

Redis采用C语言开发，目前在github上Star 47k Fork 18.5k Watch 2.7k，关注度也非常高，最近一次更新是2021年1月12日，目前最新版本为6.0.10，社区更新活跃度非常高。

在Redis中，有5种基础数据结构，分别为：string（字符串）、list（列表）、hash（字典）、set（集合）和zset（有序集合），合理的利用这些数据结构是可以达到分布式限流的效果，比如通过zset数据结构中的score值，来构造一个时间窗口，作为限流的滑动窗口，这样就可以快速的构造一个分布式限流算法。

Hystrix

Hystrix是Netflix公司开源的一款容错框架，包含常用的容错方法：线程池隔离、信号量隔离、熔断和降级回退。在高并发访问下，系统所依赖的服务的稳定性对系统的影响非常大，依赖有很多不可控的因素，比如网络连接变慢、资源突然繁忙、暂时不可用、服务宕机等。我们要构建稳定、可靠的分布式系统，就必须要有一套容错的解决方案。

Hystrix目前在github上Star 20.9k fork 4.3k Watch 1.7k，可以说关注度非常高，但是最近一次版本更新是2018年11月17日，版本为v1.5.18，已经有两年没更新代码。

Resilience4j

Resilience4j 是一个比较轻量的熔断降级库。

首先，Resilience4j 的模块化做的比较好，将每个功能点（如熔断、限速器、自动重试）都拆成了单独的模块，这样整体结构很清晰，用户也只需要引入相应功能的依赖即可。

另外，Resilience4jR是针对 Java 8 和函数式编程设计的，API 比较简洁优雅。

同时，与 Hystrix 相比，Resilience4j 增加了简单的限速器和自动重试特性，使用场景更加丰富。Resilience4j 属于一个新兴项目，社区也在蓬勃发展。

总的来说，Resilience4j 是比较轻量的库，在较小较新的项目中使用还是比较方便的。但是 Resilience4j 只包含限流降级的基本场景，对于非常复杂的企业级服务架构可能无法很好地 cover 住；同时 Resilience4j 缺乏生产级别的配套设施（如提供规则管理和实时监控能力的控制台）。

Resilience4j目前在github上Star 6.4k Fork 857 Watch 215，最近一次版本更新是2020年10月19号，最新的release版本是v1.6.1。

Sentinel

Sentinel 一款面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统自适应保护等多个维度来帮助用户保障服务的稳定性。

Sentinel 的核心思想：根据对应资源配置的规则来为资源执行相应的流控/降级/系统保护策略。在 Sentinel 中资源定义和规则配置是分离的。用户先通过 Sentinel API 给对应的业务逻辑定义资源，然后可以在需要的时候动态配置规则。

Sentinel 的优势和特性：

轻量级，核心库无多余依赖，性能损耗小；
方便接入，开源生态广泛。Sentinel对Dubbo、Spring Cloud、Web Servlet、gRPC等常用框架提供适配模块，只需引入相应依赖并简单配置即可快速接入；同时针对自定义的场景Sentinel还提供低侵入性的注解资源定义方式，方便自定义接入；
丰富的流量控制场景。Sentinel承接了阿里巴巴近10年的双十一大促流量的核心场景，流控维度包括流控指标、流控效果（塑形）、调用关系、热点、集群等各种维度，针对系统维度也提供自适应的保护机制；
易用的控制台，提供实时监控、机器发现、规则管理等能力；
完善的扩展性设计，提供多样化的 SPI 接口，方便用户根据需求给 Sentinel 添加自定义的逻辑。

对比以上几种解决方案

Nginx和Redis具备一定的分布式容错和降级能力，但是从功能完整性角度肯定是不如Sentinel、Hystrix和Resilience4j，Guava虽然也具备容错和降级能力，但是不具备分布式能力，它是基于单实例JVM的。基于以上原因，这里就对比下Sentinel、Hystrix和Resilience4j。

	Sentinel	Hystrix	Resilience4j
隔离策略	信号量隔离（并发线程数限流）	线程池隔离/信号量隔离	信号量隔离
熔断降级策略	基于响应时间、异常比率、异常数	基于异常比率	基于异常比率、响应时间
实时指标实现	滑动窗口（LeapArray）	滑动窗口（基于RxJava）	Ring Bit Buffer
动态规则配置	支持多种数据源	支持多种数据源	有限支持
扩展性	多个扩展点	插件形式	SDK形式
基于注解的支持	支持	支持	支持
限流	基于QPS限流和基于调用关系限流	有限的支持	Rate Limiter
流量整形	支持预热模式、匀速器模式和预热排队模式	不支持	简单的Rate Limiter模式
系统自适应保护	支持	不支持	不支持
控制台	提供开箱即用的控制台，可配置规则、查看秒级监控、机器治理等。	简单的监控查看	不提供控制台，可对接其它监控系统。
常见框架适配	Servlet、HttpClient、Dubbo、Spring Web等	Servlet、Spring Cloud Netflix	部分支持

总结

推荐使用Spring Cloud Alibaba+Sentinel，可以从服务治理和流量治理，两重维度去治理微服务，高效、简单并且符合主流。

公民程序员成为企业数字化的新生力

Sat, 29 Jan 2022 20:15:24 CST

2018 年一名没有编程经验的现场技术员为澳大利亚电信公司 Telstra 构建了一个应用，统一了 70 个报告电话线问题的消息系统。应用的用户界面有些凌乱，登陆页面堆满了 150 个按钮和 1 个本地新闻指示。今天有 1700 名 Telstra 技术人员在使用它，为公司每年节省了 1200 万美元。这种零编程/编程量非常少的应用开发模式已成为一种趋势，让没有经过专业训练的公民程序员成为企业数字化的新生力。研究公司 Evans Data Corporation 估计，全世界有大约 2500 万人精通标准编程语言，而程序员的需求缺口有 140 万。到 2025 年缺口将会进一步增加到 400 万。IDC 估计在 2021 年全世界有 260 万低代码/零编程开发者，2025 年前他们的人数将会每年增长 40%。微软的零编程平台 Power Apps 月活跃用户有 1000 万，它的 Visual Basic 语言是低代码/零编程的早期尝试。对这一趋势的质疑仍然存在，专业程序员指出，零编程平台让一个应用九成五的功能很容易实现，但剩余 5% 的功能几乎不可能实现。专业程序员仍然会是企业产品和关键业务系统开发的主力军，他们将会得到越来越多具有编程能力的企业员工的帮助。

程序员的酒后真言

Mon, 28 Jun 2021 09:10:50 CST

美国最大的论坛 Reddit，最近有一个热帖。

一个程序员说自己喝醉了，软件工程师已经当了10年，心里有好多话想说，"我可能会后悔今天说了这些话。"

他洋洋洒洒写了一大堆，获得9700多个赞。内容很有意思，值得一读，下面是节选。

（1）职业发展的最好方法是换公司。

（2）技术栈不重要。技术领域有大约 10-20 条核心原则，重要的是这些原则，技术栈只是落实它们的方法。你如果不熟悉某个技术栈，不需要过度担心。

（3）工作和人际关系是两回事。有一些公司，我交到了好朋友，但是工作得并不开心；另一些公司，我没有与任何同事建立友谊，但是工作得很开心。

（4）我总是对经理实话实说。怕什么？他开除我？我会在两周内找到一份新工作。

（5）如果一家公司的工程师超过 100 人，它的期权可能在未来十年内变得很有价值。对于工程师人数很少的公司，期权一般都是毫无价值。

（6）好的代码是初级工程师可以理解的代码。伟大的代码可以被第一年的 CS 专业的新生理解。

（7）作为一名工程师，最被低估的技能是记录。说真的，如果有人可以教我怎么写文档，我会付钱，也许是 1000 美元。

（8）网上的口水战，几乎都无关紧要，别去参与。

（9）如果我发现自己是公司里面最厉害的工程师，那就该离开了。

（10）我们应该雇佣更多的实习生，他们很棒。那些精力充沛的小家伙用他们的想法乱搞。如果他们公开质疑或批评某事，那就更好了。我喜欢实习生。

（11）技术栈很重要。如果你使用 Python 或 C++ 语言，就会忍不住想做一些非常不同的事情。因为某些工具确实擅长某些工作。

（12）如果你不确定自己想做什么东西，请使用 Java。这是一种糟糕的编程语言，但几乎无所不能。

（13）对于初学者来说，最赚钱的编程语言是 SQL，干翻所有其他语言。你只了解 SQL 而不会做其他事情，照样赚钱。人力资源专家的年薪？也许5万美元。懂 SQL 的人力资源专家？9万美元。

（14）测试很重要，但 TDD （测试驱动的开发）几乎变成了一个邪教。

（15）政府单位很轻松，但并不像人们说的那样好。对于职业生涯早期到中期的工程师，12 万美元的年薪 + 各种福利 + 养老金听起来不错，但是你将被禁锢在深奥的专用工具里面，离开政府单位以后，这些知识就没用了。我非常尊重政府工作人员，但说真的，这些地方的工程师，年龄中位数在 50 岁以上是有原因的。

（16）再倒一杯酒。

（17）大多数头衔都无关紧要，随便什么公司都可以有首席工程师。

（18）手腕和背部的健康问题可不是开玩笑的，好的设备值得花钱。

（19）当一个软件工程师，最好的事情是什么？你可以结识很多想法相同的人，大家互相交流，不一定有相同的兴趣，但是对方会用跟你相同的方式思考问题，这很酷。

（20）有些技术太流行，我不得不用它。我心里就会很讨厌这种技术，但会把它推荐给客户，比如我恨 Jenkins，但把它推荐给新客户，我不觉得做错了。

（21）成为一名优秀的工程师意味着了解最佳实践，成为高级工程师意味着知道何时打破最佳实践。

（22）发生事故时，如果周围的人试图将责任归咎于外部错误或底层服务中断，那么是时候离开这家公司，继续前进了。

（23）我遇到的最好的领导，同意我的一部分观点，同时耐心跟我解释，为什么不同意我的另一部分观点。我正在努力成为像他们一样的人。

（24）算法和数据结构确实重要，但不应该无限夸大，尤其是面试的时候。我没见过药剂师面试时，还要测试有机化学的细节。这个行业的面试过程有时候很糟糕。

（25）做自己喜欢的事情并不重要，不要让我做讨厌的事情更重要。

（26）越接近产品，就越接近推动收入增长。无论工作的技术性如何，只要它接近产品，我都感到越有价值。

（27）即使我平时用 Windows 工作，Linux 也很重要。为什么？因为服务器是 Linux 系统，你最终在 Linux 系统上工作。

（28）人死了以后，你想让代码成为你的遗产吗？如果是那样，就花很多时间在代码上面吧，因为那是你的遗产。但是，如果你像我一样，更看重与家人、朋友和生活中其他人相处的时光，而不是写的代码，那就别对它太在意。

（29）我挣的钱还不错，对此心存感激，但还是需要省钱。

（30）糟糕，我没酒了。

（完）

文档信息

版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）
发表日期： 2021年6月28日

程序员应该掌握的常用网络问题定位工具

Thu, 06 May 2021 18:08:56 CST

项目日常运维的过程中，经常会遇到各种奇奇怪怪的网络问题。那么排查网络问题，就成为一个合格的程序员必备技能。这里列举出一些常用的指令，用于日常工作中快速定位网络问题。

ping

这个是大家经常用到的一个小工具，用于检查两台服务器之间是否能够成功交换数据包。 ping指令向对方主机发送 ICMP报文。当能成功 ping通时表示两台主机之间的网络链路是畅通的。如果 ping不通，首先需要确认对方是否关停了 ping服务，如果没有关停，就需要检查双方的网络链接问题了。

telnet

该指令主要用于检查到对方端口的网络联通性，如果 telnet能通，一般证明 TCP三次握手已经建立成功，也就是网络层是畅通的。如果 telnet不通，需要确认对方是否已经启动相应服务端口，如果已启动，那么就要检查双方的防火墙策略等问题。

ifconfig

ifconfig 指令除了可以查看网卡信息外，还可以修改网络配置。比如查看网卡信息 ifconfig -a ；启动网卡 ifconfig eth0 up ；关停网卡 ifconfig eth0 down等操作。

除了使用 ifconfig 查看及配置网卡信息外，还可以通过 ip link show 查看网卡信息，启动网卡信息 ip link set down eth0; 关停网卡 ip link set up eth1 等操作。

注意：启动关停网卡在 SSH链接的情况下，尽量不要操作。

route

route 指令一般用于查看和配置服务器路由信息。比如查看路由信息 route -n 或者 route -nee 添加或者删除路由信息 route {add | del } -net {NETWORK-ADDRESS} netmask {NETMASK} dev {INTERFACE-NAME} 等等。

同样，除了使用 route指令外也可以使用 ip route show 查看路由信息；和 route -n 是等效的。这里更推荐使用 ip route 命令。

traceroute

该指令用于查看从源地址到目的地址的路由路径。比如 traceroute www.baidu.com 用于判断你和目标地址之间经过了哪些网络设备。 windows下是 tracert

netstat

这个指令比较强大，也是程序员日常用的比较多的一个指令。该指令可以显示服务器的网络状态，比如，显示服务器当前所有 socket链接 netstat -a; 显示 UDP/TCP端口的使用情况 netstat -apu/netstat -apt; 显示网络统计信息 netstat -s; 查看 8080端口的状态 netstat -anp|grep 8080。

和 netstat等价的指令是 ss指令。 ss -l 列出所有本机已经打开的端口。 ss -t/u -a 显示所有 tcp/udp链接。查看某个链接属于哪个进程 ss -tp。查看本地的端口状态 ss -t src ip:8080。这里更推荐使用 ss指令。

tcpdump

网络抓包工具，当遇到奇怪的网络问题时，通过 tcpdump进行网络抓包，然后进行分析定位问题。根据源IP进行抓包 tcpdump -i eth2 src 192.168.199.100 即只抓取通过 eth2这块网卡的且源地址为 192.168.199.100的网络包。当然也可以指定端口抓包，比如 tcpdump src port 8088。总之该命令非常强大，这里不做更多的详细介绍，感兴趣的可以自行了解。

nmap

这是一个网络嗅探和扫描工具，做网络安全的小伙伴会比较熟悉。经常用来检查对方主机开放了哪些端口。比如查看对方主机开放了哪些端口 nmap -PS 192.168.199.100，还可以探测目标IP的操作系统 nmap -O 192.168.199.100。总之该命令做网络安全的会用的比较多，程序员使用的会比较少一些，感兴趣的可以深入研究，该指令及其强大。

总结

上面提到的小工具，对于有些问题的定位，可以通过两个不同的指令达到同样的效果。比如 ifconfig -a 和 ip link show ； route -n 和 ip route show；以及 netstat和 ss。出现这样的情况是因为， ifconfig 和 netstat等命令来自于 net-tools工具包，而 ip link 和 ss 等指令来自 iproute2工具包。 net-tools已经停止开发了，在很多新版的操作系统里面已经不是默认自带的工具包了，如果想使用需要单独安装。 iproute2是用来替换 net-tools的，很多新版 linux都是默认安装的。而且 iproute2包中的很多指令在功能和性能上都要比 net-tools包中提供的指令更强大。我这里从网上找了一张图片用来说明俩个工具包的指令对比。

原文链接： https://mp.weixin.qq.com/s/zj4yBgi7QkWunD4mrG4p5A，关注基础编程，注重经验分享及个人成长。

😍 数仓规范篇、02.开发规范 - 白程序员的自习室

Thu, 08 Apr 2021 11:52:26 CST

HIVE SQL 作为数仓操作语言，良好的代码习惯能我们高效地完成数据分析工作。除了根据 SQL 执行顺序上的优化外，按以下规范编写 SQL 代码既能使代码更加清晰，方便自己后期维护，也方便其他同事接手。

一、注释规范

注释内容要清晰明了，含义准确，避免歧义
字段注释紧跟在字段后面
应对不易理解的分支条件表达式加注释
对重要的计算应说明其功能
过长的函数实现，应将其语句按实现的功能分段加以概括性说明
原则上所有表、字段、任务都需要添加注释，任务有特定的注释规范，见下文任务注释说明

任务注释说明

-- [hive][ads][营销类应收未付明细报表]ads_fin_receivable_unpaid_marketing_detail_df            
            
-- **************************************************************************            
-- ** 创建者   : baihe            
-- ** 创建日期 : 20210326            
-- ** 功能描述 ：营销类应收未付明细报表            
-- **************************************************************************            
-- **************************** 修改日志 *************************************            
-- 2021.3.10 修正应收未付金额算法逻辑为直接取值            
--            
-- **************************************************************************            
-- ** 依赖表：            
--				dws_fin_receivable_unpaid_marketing_detail_df				营销类应收未付汇总表            
--            
-- **************************************************************************            
-- ** 输出表：            
--          ads_fin_receivable_unpaid_marketing_detail_df      营销类应收未付明细报表            
-- **************************************************************************            
--            
-- *******************  CURRENT_VERSION ： V.1.1  ***************************            
-- **************************************************************************

任务注释注意事项补充

1、提供任务名，方便任务创建时任务的获取以及平台中任务查询
2、提供创建者、创建日期、功能描述等信息，方便后期维护跟踪
2、提供代码变更历史，便于了解代码演进历史及依据
3、提供脚本依赖表清单，方便后续任务依赖配置
4、提供输出表清单，方便确认是否单个目标表

二、存储格式规范

所谓的存储格式就是在Hive建表的时候指定的将表中的数据按照什么样子的存储方式，如果指定了方式，那么在向表中插入数据的时候，将会使用该方式向HDFS中添加相应的数据类型。建表如果无特殊要求，一律使用下面的row format格式及存储格式。

1 2	row format serde 'org.apache.hadoop.hive.serde2.columnar.ColumnarSerDe' stored as RCFile;

三、建表语句规范

--参考实例            
create table if not exists ads_sg.ads_fin_receivable_unpaid_marketing_detail_df            
(            
`business_id`        STRING comment '关联id',            
`contract_id`        STRING comment '合同id',            
`region_id`          STRING COMMENT '所属大区ID',            
`region_name`        STRING COMMENT '所属大区',            
`city_company_id`    STRING COMMENT '所属城市公司ID',            
`city_company_name`  STRING COMMENT '所属城市公司名称',            
`plaza_id`           STRING COMMENT '广场主数据id',            
`plaza_name`         STRING COMMENT '广场简称',            
`category`           STRING COMMENT '类别',            
`budget_amt`         DECIMAL(18, 2) COMMENT '预算金额',            
`contract_type`      STRING COMMENT '合同类型',            
`supplier_name`      STRING COMMENT '乙方单位',            
`contract_amt`       DECIMAL(18, 2) COMMENT '合同金额',            
`change_amt`         DECIMAL(18, 2) COMMENT '预计变更金额',            
`sign_off_amt`       DECIMAL(18, 2) COMMENT '预计结算金额',            
`payable_amt`        DECIMAL(18, 2) COMMENT '累计应付金额',            
`payable_rat`        DECIMAL(18, 4) COMMENT '累计应付比例',            
`payment_amt`        DECIMAL(18, 2) COMMENT '累计已付金额',            
`unpaid_amt`         DECIMAL(18, 2) COMMENT '累计应付未付金额（计算）',            
`is_acceptance_form` INT COMMENT '是否有验收单',            
`acceptance_time`    STRING COMMENT '验收时间',            
`risk_prompt`        STRING COMMENT '风险提示',            
`last_update_time`   timestamp() COMMENT 'etl时间'            
)            
comment '营销类应收未付明细报表'            
partitioned by ( stat_date bigint comment '日期分区')            
row format serde 'org.apache.hadoop.hive.serde2.columnar.ColumnarSerDe'            
stored as RCFile;

四、数据类型规范

1、一般情况下大部分字段都采用 string类型
2、金额类及其它小数点数据等非整型数据统一使用decimal
3、分区字段比较特殊，在数仓中统一使用bigint（平台特性原因），非平台项目可以使用date或string
4、金额类数据如果单位是元，则采用 decimal(16,4)长度类型，如果单位是万元或亿元，则采用 decimal(10,6)长度类型，其它数据字段类型视具体情况而定
5、整形数值统一使用BIGINT或INT，最大值10位及以上的整数使用BIGINT，最大值在3-9位的整数使用INT
6、时间类型数据不做具体要求，可以使用string、也可以根据日期格式使用 date或timestamp，对于只包含年月日的数据字段可采用 date类型；对于既包含年月日也包含时分秒的数据字段可采用 timestamp类型

五、SQL编码原则及规范

1、SELECT 查询语句中禁止使用 select *，所有操作必须明确指定列名
2、QL代码中应用到的所有关键字、保留字都使用大写，如select、from、where、and、or、union、insert、delete、group、having、count等。
3、SQL语句多表连表时，应使用表的别名，同时表别名形式来引用列
4、SELECT语句排列样式上，对于字段应每行一个进行编排，两个字段之间的逗号分割符紧跟在第一个字段后面或第二个字段的前面，as语句应与相应的字段在同一行,多个字段的as建议尽量对齐在同一列上

5、CASE语句的编写排列样式上，when语句应在case语句下一行，缩进一个缩进量后开始编写，每个when语句一行，当然如果语句较长可换行编排，case语句必须包含else子语，else子句与when子句对齐。

6、SQL代码中应用到的除关键字、保留字之外的代码，也都使用小写，如字段名、表别名等
7、代码中开发人员应有必要的注释从而增加代码的可读性
8、开发人员编写的代码应功能完善及健壮，同时注重美观行列段落划分整洁清晰
9、代码编写应充分考虑执行速度最有原则

六、空值处理

对于表中的空值，尽量用如下规则统一，如果有特殊情况请视情况而定。

字段类型	空值替换值
STRING	-
DECIMAL(16,4)	0.0000
DECIMAL(16,2)	0.00
FLOAT	0.00
INT、BIGINT	0
DATE	1970-01-01
TIMESTAMP	1970-01-01 00:00:00

特殊说明：
一般而言上述情况基本可以满足需求，但是不排除有特殊情况，需求要求不按照上述规范或者上述不足覆盖的场景，视情况而定。除了将空值替换为特定的值之外，业务也有直接过滤掉数据的情况。

规范要求的项，并非强制性约束，在实际应用中在不违反常规要求的前提下允许存在可理解的偏差。同时在研发过程中，如遇到问题以及好的建议，及时沟通补充此规范。也希望规范在对日常的代码开发工作起到指导作用的同时也将得到不断的完善和补充。

数据仓库命名规范：

https://www.studytime.xin/article/datawarehouse-naming-conventions.html

spring-cloud-kubernetes的服务发现和轮询实战(含熔断)_程序员欣宸的博客-CSDN博客

Sun, 01 Nov 2020 08:38:35 CST

本文是《spring-cloud-kubernetes实战系列》的第四篇，主要内容是在kubernetes上部署两个应用：Web-Service和Account-Service，通过spring-cloud-kubernetes提供的注册发现能力，实现Web-Service调用Account-Service提供的http服务；

系列文章列表

全文概览

本文由以下段落组成：

环境信息
常见的SpringCloud注册发现服务一览
分析kubernetes上如何实现服务注册发现
本章实战源码下载链接
实战开发Account-Service服务(服务提供方)
实战开发Web-Service服务(服务消费方)
扩容验证ribbon轮询能力
验证熔断能力

环境信息

本次实战的环境和版本信息如下：

操作系统：CentOS Linux release 7.6.1810
minikube：1.1.1
Java：1.8.0_191
Maven：3.6.0
fabric8-maven-plugin插件：3.5.37
spring-cloud-kubernetes：1.0.1.RELEASE

上面的linux、minikube、java、maven，请确保已准备好，linux环境下minikube的安装和启动请参考《Linux安装minikube指南》。

常见的SpringCloud注册发现服务一览

SpringCloud环境最重要的功能是注册发现服务，因此将SpringCloud应用迁移到kubernetes环境时，开发者最关心的问题是在kubernetes上如何将自身服务暴露出去，以及如何调用其他微服务。

先看看普通SpringCloud环境下的注册发现，下图来自spring官方博客，地址是： https://spring.io/blog/2015/07/14/microservices-with-spring，

由上图可见，应用Account-Service将自己注册到Eureka，这样Web-Service用"account-service"就能在Eureka找到Account-Service服务的地址，然后顺利发送RestFul请求到Account-Service，用上其提供的服务。

分析kubernetes上如何实现服务注册发现

如果将上面的Web-Service和Account-Service两个应用迁移到kubernetes上之后，注册发现机制变成了啥样呢？
第一种：沿用上图的方式，将Eureka也部署在kubernetes上，这样的架构和不用kubernetes时没有啥区别；
第二种，就是今天要实战的内容，使用spring-cloud-kubernetes框架，该框架可以调用kubernetes的原生能力来为现有SpringCloud应用提供服务，架构如下图所示：

上图表明，Web-Service应用在调用Account-Service应用的服务时，会用okhttp向API Server请求服务列表，API Server收到请求后会去etcd取数据返回给Web-Service应用，这样Web-Service就有了Account-Service的信息，可以向Account-Service的多个Pod轮询发起请求；

上图有个细节请注意：WebService应用并不是直接将请求发送给Account-Service在kubernetes创建的service，而是直接发送到具体的Pod上了，之所以具有这个能力，是因为spring-cloud-kubernetes框架通过service拿到了Account-Service对应的所有Pod信息（endpoint），此逻辑可以参考源码KubernetesServerList.java，如下所示：

      publicList<Server>getUpdatedListOfServers(){//用namespace和serviceId做条件，得到该服务对应的所有节点(endpoints)信息Endpoints endpoints=this.namespace!=null?this.client.endpoints().inNamespace(this.namespace).withName(this.serviceId).get():this.client.endpoints().withName(this.serviceId).get();List<Server>result=newArrayList<Server>();if(endpoints!=null){if(LOG.isDebugEnabled()){LOG.debug("Found ["+endpoints.getSubsets().size()+"] endpoints in namespace ["+this.namespace+"] for name ["+this.serviceId+"] and portName ["+this.portName+"]");}//遍历所有的endpoint，取出IP地址和端口，构建成Server实例，放入result集合中for(EndpointSubset subset:endpoints.getSubsets()){if(subset.getPorts().size()==1){EndpointPort port=subset.getPorts().get(FIRST);for(EndpointAddress address:subset.getAddresses()){result.add(newServer(address.getIp(),port.getPort()));}}else{for(EndpointPort port:subset.getPorts()){if(Utils.isNullOrEmpty(this.portName)||this.portName.endsWith(port.getName())){for(EndpointAddress address:subset.getAddresses()){result.add(newServer(address.getIp(),port.getPort()));}}}}}}else{LOG.warn("Did not find any endpoints in ribbon in namespace ["+this.namespace+"] for name ["+this.serviceId+"] and portName ["+this.portName+"]");}returnresult;}

理论分析已经完成，接下来就开始实战吧

源码下载

如果您不打算写代码，也可以从GitHub上下载本次实战的源码，地址和链接信息如下表所示：

名称	链接	备注
项目主页	https://github.com/zq2599/blog_demos	该项目在GitHub上的主页
git仓库地址(https)	https://github.com/zq2599/blog_demos.git	该项目源码的仓库地址，https协议
git仓库地址(ssh)	git@github.com:zq2599/blog_demos.git	该项目源码的仓库地址，ssh协议

这个git项目中有多个文件夹，本章的Account-Service源码在spring-cloud-k8s-account-service文件夹下，Web-Service源码在spring-cloud-k8s-web-service文件夹下，如下图红框所示：

下面是详细的编码过程；

开发和部署Account-Service服务

Account-Service服务是个很普通的springboot应用，和spring-cloud-kubernetes没有任何关系：

通过maven创建一个springboot应用，artifactId是account-service，pom.xml内容如下：

      <?xml version="1.0" encoding="UTF-8"?><projectxmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>2.1.1.RELEASE</version><relativePath/><!-- lookup parent from repository --></parent><groupId>com.bolingcavalry</groupId><artifactId>account-service</artifactId><version>0.0.1-SNAPSHOT</version><name>account-service</name><description>Demo project for Spring Cloud service provider run in kubernetes</description><properties><java.version>1.8</java.version><spring-boot.version>2.1.1.RELEASE</spring-boot.version><maven-checkstyle-plugin.failsOnError>false</maven-checkstyle-plugin.failsOnError><maven-checkstyle-plugin.failsOnViolation>false</maven-checkstyle-plugin.failsOnViolation><maven-checkstyle-plugin.includeTestSourceDirectory>false</maven-checkstyle-plugin.includeTestSourceDirectory><maven-compiler-plugin.version>3.5</maven-compiler-plugin.version><maven-deploy-plugin.version>2.8.2</maven-deploy-plugin.version><maven-failsafe-plugin.version>2.18.1</maven-failsafe-plugin.version><maven-surefire-plugin.version>2.21.0</maven-surefire-plugin.version><fabric8.maven.plugin.version>3.5.37</fabric8.maven.plugin.version><springcloud.version>2.1.1.RELEASE</springcloud.version></properties><dependencyManagement><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-dependencies</artifactId><type>pom</type><scope>import</scope><version>${spring-boot.version}</version></dependency></dependencies></dependencyManagement><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter</artifactId><version>${springcloud.version}</version></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId><version>${springcloud.version}</version></dependency></dependencies><build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><version>${spring-boot.version}</version><executions><execution><goals><goal>repackage</goal></goals></execution></executions></plugin><plugin><!--skip deploy --><groupId>org.apache.maven.plugins</groupId><artifactId>maven-deploy-plugin</artifactId><version>${maven-deploy-plugin.version}</version><configuration><skip>true</skip></configuration></plugin><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-surefire-plugin</artifactId><version>${maven-surefire-plugin.version}</version><configuration><skipTests>true</skipTests><!-- Workaround for https://issues.apache.org/jira/browse/SUREFIRE-1588 --><useSystemClassLoader>false</useSystemClassLoader></configuration></plugin><plugin><groupId>io.fabric8</groupId><artifactId>fabric8-maven-plugin</artifactId><version>${fabric8.maven.plugin.version}</version><executions><execution><id>fmp</id><goals><goal>resource</goal></goals></execution></executions></plugin></plugins></build><profiles><profile><id>kubernetes</id><build><plugins><plugin><groupId>io.fabric8</groupId><artifactId>fabric8-maven-plugin</artifactId><version>${fabric8.maven.plugin.version}</version><executions><execution><id>fmp</id><goals><goal>resource</goal><goal>build</goal></goals></execution></executions><configuration><enricher><config><fmp-service><type>NodePort</type></fmp-service></config></enricher></configuration></plugin></plugins></build></profile></profiles></project>

由上面的pom.xml内容可见，account-service应用是个简单的web应用，和SpringCloud、spring-cloud-kubernetes都没有任何关系，和其他springboot唯一的不同就是用到了fabric8-maven-plugin插件，可以方便的将应用部署到kubernetes环境；

application.yml内容如下，依旧很简单：

      spring:application:name:account-serviceserver:port:8080

对外提供服务的是AccountController ，方法getName返回了当前容器的hostname，方法health用于响应kubernetes的两个探针，方法ribbonPing用于响应使用了ribbon服务的调用方，它们会调用这个接口来确定当前服务是否正常：

      @RestControllerpublicclassAccountController{privatestaticfinalLogger LOG=LoggerFactory.getLogger(AccountController.class);privatefinalString hostName=System.getenv("HOSTNAME");/**
     * 探针检查响应类
     * @return
     */@RequestMapping("/health")publicStringhealth(){return"OK";}@RequestMapping("/")publicStringribbonPing(){LOG.info("ribbonPing of {}",hostName);returnhostName;}/**
     * 返回hostname
     * @return 当前应用所在容器的hostname.
     */@RequestMapping("/name")publicStringgetName(){returnthis.hostName+", "+newSimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(newDate());}}

将上述工程的源码放在minikube机器上，确保maven设置正常，然后在pom.xml文件所在目录执行以下命令，即可编译构建工程并部署到kubernetes上：

      mvn cleaninstallfabric8:deploy -Dfabric8.generator.from=fabric8/java-jboss-openjdk8-jdk -Pkubernetes

执行成功后控制台输出如下：

      ...[INFO]Installing /usr/local/work/k8s/ribbon/spring-cloud-k8s-account-service/target/classes/META-INF/fabric8/kubernetes.json to /root/.m2/repository/com/bolingcavalry/account-service/0.0.1-SNAPSHOT/account-service-0.0.1-SNAPSHOT-kubernetes.json[INFO][INFO]<<<fabric8-maven-plugin:3.5.37:deploy(default-cli)<install@ account-service<<<[INFO][INFO][INFO]--- fabric8-maven-plugin:3.5.37:deploy(default-cli)@ account-service ---[INFO]F8: Using Kubernetes at https://192.168.121.133:8443/innamespace default with manifest /usr/local/work/k8s/ribbon/spring-cloud-k8s-account-service/target/classes/META-INF/fabric8/kubernetes.yml[INFO]Using namespace: default[INFO]Updating a Service from kubernetes.yml[INFO]Updated Service: target/fabric8/applyJson/default/service-account-service.json[INFO]Using namespace: default[INFO]Updating Deployment from kubernetes.yml[INFO]Updated Deployment: target/fabric8/applyJson/default/deployment-account-service.json[INFO]F8: HINT: Use thecommand`kubectl get pods -w`towatchyour pods start up[INFO]------------------------------------------------------------------------[INFO]BUILD SUCCESS[INFO]------------------------------------------------------------------------[INFO]Total time:  11.941 s[INFO]Finished at: 2019-06-16T19:00:51+08:00[INFO]------------------------------------------------------------------------

检查kubernetes上的部署和服务是否正常：

      [root@minikube spring-cloud-k8s-account-service]# kubectl get deploymentsNAME              READY   UP-TO-DATE   AVAILABLE   AGE
account-service   1/1     1            1           69m[root@minikube spring-cloud-k8s-account-service]# kubectl get servicesNAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)AGE
account-service   NodePort    10.105.157.201<none>8080:32596/TCP   69m
kubernetes        ClusterIP   10.96.0.1<none>443/TCP          8d

minikube的service命令可以得到指定服务的访问地址：

      [root@minikube spring-cloud-k8s-account-service]# minikube service account-service --urlhttp://192.168.121.133:32596

可见account-service的服务可以通过这个url访问： http://192.168.121.133:32596

用浏览器访问地址： http://192.168.121.133:32596/name，如下图所示，可以正常访问account-service提供的服务：

现在account-service服务已经就绪，接下来是开发和部署web-service应用。

开发和部署Web-Service服务

Web-Service服务是个springboot应用，用到了spring-cloud-kubernetes提供的注册发现能力，以轮询的方式访问指定服务的全部pod：

通过maven创建一个springboot应用，artifactId是web-service，pom.xml内容如下，要重点关注的是spring-cloud-starter-kubernetes-ribbon的依赖：

      <?xml version="1.0" encoding="UTF-8"?><projectxmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>2.1.1.RELEASE</version><relativePath/><!-- lookup parent from repository --></parent><groupId>com.bolingcavalry</groupId><artifactId>web-service</artifactId><version>0.0.1-SNAPSHOT</version><name>web-service</name><description>Demo project for Spring Cloud service consumer run in kubernetes</description><properties><java.version>1.8</java.version><spring-boot.version>2.1.1.RELEASE</spring-boot.version><maven-checkstyle-plugin.failsOnError>false</maven-checkstyle-plugin.failsOnError><maven-checkstyle-plugin.failsOnViolation>false</maven-checkstyle-plugin.failsOnViolation><maven-checkstyle-plugin.includeTestSourceDirectory>false</maven-checkstyle-plugin.includeTestSourceDirectory><maven-compiler-plugin.version>3.5</maven-compiler-plugin.version><maven-deploy-plugin.version>2.8.2</maven-deploy-plugin.version><maven-failsafe-plugin.version>2.18.1</maven-failsafe-plugin.version><maven-surefire-plugin.version>2.21.0</maven-surefire-plugin.version><fabric8.maven.plugin.version>3.5.37</fabric8.maven.plugin.version><springcloud.kubernetes.version>1.0.1.RELEASE</springcloud.kubernetes.version><springcloud.version>2.1.1.RELEASE</springcloud.version></properties><dependencyManagement><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-dependencies</artifactId><type>pom</type><scope>import</scope><version>${spring-boot.version}</version></dependency></dependencies></dependencyManagement><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-kubernetes-core</artifactId><version>${springcloud.kubernetes.version}</version></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-kubernetes-discovery</artifactId><version>${springcloud.kubernetes.version}</version></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-kubernetes-ribbon</artifactId><version>${springcloud.kubernetes.version}</version></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-commons</artifactId><version>${springcloud.version}</version></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter</artifactId><version>${springcloud.version}</version></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId><version>${springcloud.version}</version></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-ribbon</artifactId><version>${springcloud.version}</version></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-hystrix</artifactId><version>${springcloud.version}</version></dependency></dependencies><build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><version>${spring-boot.version}</version><executions><execution><goals><goal>repackage</goal></goals></execution></executions></plugin><plugin><!--skip deploy --><groupId>org.apache.maven.plugins</groupId><artifactId>maven-deploy-plugin</artifactId><version>${maven-deploy-plugin.version}</version><configuration><skip>true</skip></configuration></plugin><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-surefire-plugin</artifactId><version>${maven-surefire-plugin.version}</version><configuration><skipTests>true</skipTests><!-- Workaround for https://issues.apache.org/jira/browse/SUREFIRE-1588 --><useSystemClassLoader>false</useSystemClassLoader></configuration></plugin><plugin><groupId>io.fabric8</groupId><artifactId>fabric8-maven-plugin</artifactId><version>${fabric8.maven.plugin.version}</version><executions><execution><id>fmp</id><goals><goal>resource</goal></goals></execution></executions></plugin></plugins></build><profiles><profile><id>kubernetes</id><build><plugins><plugin><groupId>io.fabric8</groupId><artifactId>fabric8-maven-plugin</artifactId><version>${fabric8.maven.plugin.version}</version><executions><execution><id>fmp</id><goals><goal>resource</goal><goal>build</goal></goals></execution></executions><configuration><enricher><config><fmp-service><type>NodePort</type></fmp-service></config></enricher></configuration></plugin></plugins></build></profile></profiles></project>

application.yml的内容如下，增加了熔断的配置：

      spring:application:name:web-serviceserver:port:8080backend:ribbon:eureka:enabled:falseclient:enabled:trueServerListRefreshInterval:5000hystrix.command.BackendCall.execution.isolation.thread.timeoutInMilliseconds:5000hystrix.threadpool.BackendCallThread.coreSize:5

创建一个ribbon的配置类RibbonConfiguration：

      packagecom.bolingcavalry.webservice;importcom.netflix.client.config.IClientConfig;importcom.netflix.loadbalancer.AvailabilityFilteringRule;importcom.netflix.loadbalancer.IPing;importcom.netflix.loadbalancer.IRule;importcom.netflix.loadbalancer.PingUrl;importorg.springframework.beans.factory.annotation.Autowired;importorg.springframework.context.annotation.Bean;/**
 * @Description: ribbon配置类
 * @author: willzhao E-mail: zq2599@gmail.com
 * @date: 2019/6/16 11:52
 */publicclassRibbonConfiguration{@AutowiredIClientConfig ribbonClientConfig;/**
     * 检查服务是否可用的实例，
     * 此地址返回的响应的返回码如果是200表示服务可用
     * @param config
     * @return
     */@BeanpublicIPingribbonPing(IClientConfig config){returnnewPingUrl();}/**
     * 轮询规则
     * @param config
     * @return
     */@BeanpublicIRuleribbonRule(IClientConfig config){returnnewAvailabilityFilteringRule();}}

应用启动类如下，注意增加了服务发现、熔断、ribbon的配置，还定义了restTemplte实例，注意@LoadBalanced注解：

      packagecom.bolingcavalry.webservice;importorg.springframework.boot.SpringApplication;importorg.springframework.boot.autoconfigure.SpringBootApplication;importorg.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker;importorg.springframework.cloud.client.discovery.EnableDiscoveryClient;importorg.springframework.cloud.client.loadbalancer.LoadBalanced;importorg.springframework.cloud.netflix.ribbon.RibbonClient;importorg.springframework.context.annotation.Bean;importorg.springframework.web.client.RestTemplate;@SpringBootApplication@EnableDiscoveryClient@EnableCircuitBreaker@RibbonClient(name="account-service",configuration=RibbonConfiguration.class)publicclassWebServiceApplication{publicstaticvoidmain(String[]args){SpringApplication.run(WebServiceApplication.class,args);}@LoadBalanced@BeanRestTemplaterestTemplate(){returnnewRestTemplate();}}

远程调用account-service的http接口的逻辑被放进服务类AccountService中，注意URL中用的是服务名account-service：

      packagecom.bolingcavalry.webservice;importcom.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;importcom.netflix.hystrix.contrib.javanica.annotation.HystrixProperty;importorg.springframework.beans.factory.annotation.Autowired;importorg.springframework.stereotype.Service;importorg.springframework.web.client.RestTemplate;importjava.text.SimpleDateFormat;importjava.util.Date;/**
 * @Description: 这里面封装了远程调用account-service提供服务的逻辑
 * @author: willzhao E-mail: zq2599@gmail.com
 * @date: 2019/6/16 12:21
 */@ServicepublicclassAccountService{@AutowiredprivateRestTemplate restTemplate;@HystrixCommand(fallbackMethod="getFallbackName",commandProperties={@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="1000")})publicStringgetDataFromSpringCloudK8SProvider(){returnthis.restTemplate.getForObject("http://account-service/name",String.class);}/**
     * 熔断时调用的方法
     * @return
     */privateStringgetFallbackName(){return"Fallback"+", "+newSimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(newDate());}}

最后是响应web请求的WebServiceController类，这里面调用了AccountService的服务，这样我们从web发起请求后，web-service就会远程调用account-service的服务：

      packagecom.bolingcavalry.webservice;importorg.springframework.beans.factory.annotation.Autowired;importorg.springframework.web.bind.annotation.RequestMapping;importorg.springframework.web.bind.annotation.RequestParam;importorg.springframework.web.bind.annotation.RestController;/**
 * @Description: 测试用的controller，会远程调用account-service的服务
 * @author: willzhao E-mail: zq2599@gmail.com
 * @date: 2019/6/16 11:46
 */@RestControllerpublicclassWebServiceController{@AutowiredprivateAccountService accountService;/**
     * 探针检查响应类
     * @return
     */@RequestMapping("/health")publicStringhealth(){return"OK";}/**
     * 远程调用account-service提供的服务
     * @return 多次远程调返回的所有结果.
     */@RequestMapping("/account")publicStringaccount(){StringBuilder sbud=newStringBuilder();for(inti=0;i<10;i++){sbud.append(accountService.getDataFromSpringCloudK8SProvider()).append("<br>");}returnsbud.toString();}}

将上述工程的源码放在minikube机器上，确保maven设置正常，然后在pom.xml文件所在目录执行以下命令，即可编译构建工程并部署到kubernetes上：

      mvn cleaninstallfabric8:deploy -Dfabric8.generator.from=fabric8/java-jboss-openjdk8-jdk -Pkubernetes

执行成功后控制台输出如下：

      ...[INFO]Installing /usr/local/work/k8s/ribbon/spring-cloud-k8s-web-service/target/classes/META-INF/fabric8/kubernetes.json to /root/.m2/repository/com/bolingcavalry/web-service/0.0.1-SNAPSHOT/web-service-0.0.1-SNAPSHOT-kubernetes.json[INFO][INFO]<<<fabric8-maven-plugin:3.5.37:deploy(default-cli)<install@ web-service<<<[INFO][INFO][INFO]--- fabric8-maven-plugin:3.5.37:deploy(default-cli)@ web-service ---[INFO]F8: Using Kubernetes at https://192.168.121.133:8443/innamespace default with manifest /usr/local/work/k8s/ribbon/spring-cloud-k8s-web-service/target/classes/META-INF/fabric8/kubernetes.yml[INFO]Using namespace: default[INFO]Creating a Service from kubernetes.yml namespace default name web-service[INFO]Created Service: target/fabric8/applyJson/default/service-web-service.json[INFO]Using namespace: default[INFO]Creating a Deployment from kubernetes.yml namespace default name web-service[INFO]Created Deployment: target/fabric8/applyJson/default/deployment-web-service.json[INFO]F8: HINT: Use thecommand`kubectl get pods -w`towatchyour pods start up[INFO]------------------------------------------------------------------------[INFO]BUILD SUCCESS[INFO]------------------------------------------------------------------------[INFO]Total time:  12.792 s[INFO]Finished at: 2019-06-16T19:24:21+08:00[INFO]------------------------------------------------------------------------

检查kubernetes上的部署和服务是否正常：

      [root@minikube spring-cloud-k8s-web-service]# kubectl get deploymentsNAME              READY   UP-TO-DATE   AVAILABLE   AGE
account-service   1/1     1            1           109m
web-service       1/1     1            1           18m[root@minikube spring-cloud-k8s-web-service]# kubectl get svcNAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)AGE
account-service   NodePort    10.105.157.201<none>8080:32596/TCP   109m
kubernetes        ClusterIP   10.96.0.1<none>443/TCP          8d
web-service       NodePort    10.99.211.179<none>8080:30519/TCP   18m

minikube的service命令可以得到指定服务的访问地址：

      [root@minikube spring-cloud-k8s-web-service]# minikube service web-service --urlhttp://192.168.121.133:30519

可见web-service的服务可以通过这个url访问： http://192.168.121.133:30519

用浏览器访问地址： http://192.168.121.133:30519/account，如下图所示，页面上展示的内容都是web-service调用了account-service的接口返回的，证明kubernetes上的注册发现能力正常：

扩容验证ribbon轮询能力

虽然web-service可以正常调用account-service的服务，但始终访问的是一个pod，接下来我们就对account-service的pod进行扩容，将数量调整为2个，看看web-service是否可以轮询调用每个account-service的pod：

执行以下命令即可将pod数量调整为2个：

      kubectl scale --replicas=2 deployment account-service

检查account-service的pod，发现已经有两个了(account-service-5554576647-m29xr和account-service-5554576647-zwwml)：

      [root@minikube spring-cloud-k8s-web-service]# kubectl get podsNAME                               READY   STATUS    RESTARTS   AGE
account-service-5554576647-m29xr   1/1     Running   0          53m
account-service-5554576647-zwwml   1/1     Running   0          20s
web-service-6d775855c7-7lkvr       1/1     Running   0          29m

用浏览器访问地址： http://192.168.121.133:30519/account，如下图所示，account-sercice返回的hostname已经变成了两种，和前面查到的pod的name一致，可见web-service的确是通过ribbon轮询访问了多个account-service的pod：

验证熔断能力

接下来验证web-service配置的熔断服务是否可以生效：

执行以下命令将account-service的deployment删除：

      kubectl delete deployment account-service

再浏览器访问地址： http://192.168.121.133:30519/account，如下图所示，页面上的"Fallback"是配置的熔断方法返回的内容，可见熔断配置已经生效：
再回到web-service的pom.xml所在位置执行以下命令，这样会重新构建部署一次web-service服务：

      mvn cleaninstallfabric8:deploy -Dfabric8.generator.from=fabric8/java-jboss-openjdk8-jdk -Pkubernetes

再浏览器访问地址： http://192.168.121.133:30519/account，如下图所示，服务成功恢复：

至此，spring-cloud-kubernetes的服务发现和轮询实战(含熔断)就全部完成了，利用API Server提供的信息，spring-cloud-kubernetes将原生的kubernetes服务带给了SpringCloud应用，帮助传统微服务更好的融合在kubernetes环境中，如果您也在考虑将应用迁移到kubernetes上，希望本文能给您一些参考。

程序员你是如何使用Nacos作为配置中心的？ - 李福春 - 博客园

Sat, 10 Oct 2020 07:42:36 CST

假如你使用的是spring-cloud-alibaba微服务技术栈

单个服务独有配置文件

即去除应用程序的状态，配置统一外部化管理，方便进行水平的伸缩。

集成步骤：

假如我有一个应用app-design;

1，引入依赖：

      <dependency>
     <groupId>com.alibaba.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
     <version>2.2.1.RELEASE</version>
 </dependency>

2, 配置文件；

      spring.cloud.nacos.config.enabled=true
spring.cloud.nacos.config.refresh-enabled=true

spring.cloud.nacos.config.server-addr=${spring.cloud.nacos.discovery.server-addr}
spring.cloud.nacos.config.namespace=${spring.cloud.nacos.discovery.namespace}

说明如下：

属性	说明
spring.cloud.nacos.config.server-addr=${spring.cloud.nacos.discovery.server-addr}	nacos配置中心地址
spring.cloud.nacos.config.namespace=${spring.cloud.nacos.discovery.namespace}	nacos的命名空间，这里跟服务发现的配置一致；

3，使用配置的方式，同本地配置文件一样。

@Value @PropertyConfiguration 这些注解都是支持的；

4，确认方式，比如把之前的application.properties的配置放到了配置中心；

本地启动的时候，读取到了8081端口和数据库连接池的配置；

配置中心的连接原理，后面单独整理出来，知其然并知其所以然。

服务之间共享配置文件

场景：多个后端微服务，在同一个集群中共用中间件的配置信息。

比如缓存redis, 消息队列kafka, 文件服务器，邮件服务器；

那么对应的配置文件没有必要在所有的后端微服务中单独存在，这些配置文件应该放在公共配置文件中，但是也可以被具体的后端微服务自己的独有配置文件覆盖，使用自己的私有配置；

可结合下图理解：

问题	回答
where are we?现状	中间件配置分散在很多服务中，配置繁琐，不方便统一管理
where are we go?目的	同一个集群的中间件只维护一份，各服务共享，也可按照需要覆盖共享的配置；
how can we go there?实现路径	基于nacos已有功能实现

下面是实际的coding过程和测试用例；

服务app-file;

在服务对应的nacos的namespace中

1 引入共享配置

      #共享中间件的配置
spring.cloud.nacos.config.shared-configs[0].data-id=mid.properties
spring.cloud.nacos.config.shared-configs[0].group=DEFAULT_GROUP
spring.cloud.nacos.config.shared-configs[0].refresh=true

位置：模块start下的src/main/resources/bootstrap.properties文件中

自描述的配置信息，即引入的共享配置文件列表有哪些，可以按照需要，配置各种中间件的配置信息；

key	说明
data-id	_the data id of extended configuration 配置文件名称，带上后缀；翻译：扩展配置文件的数据id
group	_the group of extended configuration, the default value is DEFAULT_GROUP 集群名称，从名字来看，支持多集群的配置文件翻译：扩展配置文件的集群，默认值是 DEFAULT_GROUP
refresh	_whether to support dynamic refresh, the default does not support 是否刷新翻译：是否支持动态刷新，默认不支持

花括号[0] ,里面的0是序号，如果有多个，按照数字自增顺序进行配置；

2 在nacos中新增配置文件

根据实际场景在nacos的test命名空间中新增配置文件mid.properties

3 获取配置用例测试

测试接口代码：

      @ApiOperation("测试获取公共配置文件")
    @GetMapping("/config/test")
    public Response config(){
        String redisConfigServers = environment.getProperty("redis.config.servers","null");
        return SingleResponse.of(redisConfigServers);
    }

测试用例：

场景	期望结果	实际结果	是否符合预期
获取共享配置文件中的配置	r-wz9sp7dhxjnz16bs1jzhutj.redis.rds.aliyuncs.com:6379	r-wz9sp7dhxjnz16bs1jzhutj.redis.rds.aliyuncs.com:6379	是
在服务独有app-file.properties配置中重写配置redis.config.servers=r-wz9sp7dhxjnz16bs1jzhutj.redis.rds.aliyuncs.com:637905	r-wz9sp7dhxjnz16bs1jzhutj.redis.rds.aliyuncs.com:637905	r-wz9sp7dhxjnz16bs1jzhutj.redis.rds.aliyuncs.com:637905	是

截图如下：

源码分析

掌握用法之后，深入分析源码，知其然而知其所以然；

starter调用封装

使用的starter封装；

https://github.com/alibaba/spring-cloud-alibaba/spring-cloud-alibaba-starters/spring-cloud-starter-alibaba-nacos-config

版本： 2.2.1.RELEASE

启动的时候自动装配的配置如下：

      org.springframework.cloud.bootstrap.BootstrapConfiguration=\
com.alibaba.cloud.nacos.NacosConfigBootstrapConfiguration

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.alibaba.cloud.nacos.NacosConfigAutoConfiguration,\
com.alibaba.cloud.nacos.endpoint.NacosConfigEndpointAutoConfiguration

org.springframework.boot.diagnostics.FailureAnalyzer=\
com.alibaba.cloud.nacos.diagnostics.analyzer.NacosConnectionFailureAnalyzer

分解一下key，看一下用途：

key	说明
org.springframework.cloud.bootstrap.BootstrapConfiguration	A marker interface used as a key in `META-INF/spring.factories`. Entries in the factories file are used to create the bootstrap application context.*

翻译：一个标记注解用来作为key 放在META-INF/spring.factories文件中，文件中的条目用来创建启动应用的上下文；

来源：spring-cloud-context-version.jar

value:

com.alibaba.cloud.nacos.NacosConfigBootstrapConfiguration |
| org.springframework.boot.autoconfigure.EnableAutoConfiguration | 注释太长了，不放这里.放到附录中。

来源：spring-boot-autoconfigure-version.jar

com.alibaba.cloud.nacos.NacosConfigAutoConfiguration,\

com.alibaba.cloud.nacos.endpoint.NacosConfigEndpointAutoConfiguration |
| org.springframework.boot.diagnostics.FailureAnalyzer | A {@code FailureAnalyzer} is used to analyze a failure and provide diagnostic* information that can be displayed to the user.

翻译： FailureAnalyzer用来分析错误并提供诊断信息展示给到用户

来源： spring-boot-version.jar

com.alibaba.cloud.nacos.diagnostics.analyzer.NacosConnectionFailureAnalyzer |

然后看看都自动装配了什么？以及自动装配的过程。

springboot的方式调用；

1 NacosConfigBootstrapConfiguration

源码：

      package com.alibaba.cloud.nacos;

import com.alibaba.cloud.nacos.client.NacosPropertySourceLocator;

import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;
import org.springframework.boot.autoconfigure.condition.ConditionalOnProperty;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * @author xiaojing
 */
@Configuration(proxyBeanMethods = false)
@ConditionalOnProperty(name = "spring.cloud.nacos.config.enabled", matchIfMissing = true)
public class NacosConfigBootstrapConfiguration {

	@Bean
	@ConditionalOnMissingBean
	public NacosConfigProperties nacosConfigProperties() {
		return new NacosConfigProperties();
	}

	@Bean
	@ConditionalOnMissingBean
	public NacosConfigManager nacosConfigManager(
			NacosConfigProperties nacosConfigProperties) {
		return new NacosConfigManager(nacosConfigProperties);
	}

	@Bean
	public NacosPropertySourceLocator nacosPropertySourceLocator(
			NacosConfigManager nacosConfigManager) {
		return new NacosPropertySourceLocator(nacosConfigManager);
	}

}

自动装配流程：

配置文件组装源码：

      @Override
	public PropertySource<?> locate(Environment env) {
		nacosConfigProperties.setEnvironment(env);
		ConfigService configService = nacosConfigManager.getConfigService();

		if (null == configService) {
			log.warn("no instance of config service found, can't load config from nacos");
			return null;
		}
		long timeout = nacosConfigProperties.getTimeout();
		nacosPropertySourceBuilder = new NacosPropertySourceBuilder(configService,
				timeout);
		String name = nacosConfigProperties.getName();

		String dataIdPrefix = nacosConfigProperties.getPrefix();
		if (StringUtils.isEmpty(dataIdPrefix)) {
			dataIdPrefix = name;
		}

		if (StringUtils.isEmpty(dataIdPrefix)) {
			dataIdPrefix = env.getProperty("spring.application.name");
		}

		CompositePropertySource composite = new CompositePropertySource(
				NACOS_PROPERTY_SOURCE_NAME);

		loadSharedConfiguration(composite);
		loadExtConfiguration(composite);
		loadApplicationConfiguration(composite, dataIdPrefix, nacosConfigProperties, env);

		return composite;
	}

加载应用配置文件的顺序源码：

      private void loadApplicationConfiguration(
			CompositePropertySource compositePropertySource, String dataIdPrefix,
			NacosConfigProperties properties, Environment environment) {
		String fileExtension = properties.getFileExtension();
		String nacosGroup = properties.getGroup();
		// load directly once by default
		loadNacosDataIfPresent(compositePropertySource, dataIdPrefix, nacosGroup,
				fileExtension, true);
		// load with suffix, which have a higher priority than the default
		loadNacosDataIfPresent(compositePropertySource,
				dataIdPrefix + DOT + fileExtension, nacosGroup, fileExtension, true);
		// Loaded with profile, which have a higher priority than the suffix
		for (String profile : environment.getActiveProfiles()) {
			String dataId = dataIdPrefix + SEP1 + profile + DOT + fileExtension;
			loadNacosDataIfPresent(compositePropertySource, dataId, nacosGroup,
					fileExtension, true);
		}

	}

顺序如下：

序号	说明
1	加载dataIdPrefix对应的配置文件
2	加载dataIdPrefix.fileExtension对应的配置文件
3	加载 dataIdPrefix-activeProfiles.fileExtension对应的配置文件

2.1 NacosConfigAutoConfiguration

序号	说明
1	NacosConfigProperties nacos配置
2	NacosRefreshProperties 已经不建议被使用
3	NacosRefreshHistory 刷新历史
4	NacosConfigManager 配置
5	NacosContextRefresher 注册nacos的监听器到应用

2.2 NacosConfigEndpointAutoConfiguration

NacosConfigEndpoint

本地配置同步逻辑

      @ReadOperation
	public Map<String, Object> invoke() {
		Map<String, Object> result = new HashMap<>(16);
		result.put("NacosConfigProperties", properties);

		List<NacosPropertySource> all = NacosPropertySourceRepository.getAll();

		List<Map<String, Object>> sources = new ArrayList<>();
		for (NacosPropertySource ps : all) {
			Map<String, Object> source = new HashMap<>(16);
			source.put("dataId", ps.getDataId());
			source.put("lastSynced", dateFormat.get().format(ps.getTimestamp()));
			sources.add(source);
		}
		result.put("Sources", sources);
		result.put("RefreshHistory", refreshHistory.getRecords());

		return result;
	}

NacosConfigHealthIndicator

健康检查 UP,DOWN,UNKNOWN ;

3 NacosConnectionFailureAnalyzer

连接不上nacos服务端抛出异常

      @Override
	protected FailureAnalysis analyze(Throwable rootFailure,
			NacosConnectionFailureException cause) {
		return new FailureAnalysis(
				"Application failed to connect to Nacos server: \""
						+ cause.getServerAddr() + "\"",
				"Please check your Nacos server config", cause);
	}

小结：服务通过集成该starter，通过http请求从nacos的服务端拉取配置数据，并做了配置刷新历史，注册监听器到spring容器中，本地缓存，和错误报告；

服务端封装

源码位置： https://github.com/alibaba/nacos/tree/develop/config

应用启动读取配置文件整体调用链：待后续完成；

小结

如果读完本篇文章你只能记住一句话：nacos作为配置中心可为单独的服务提供外部化配置文件，也支持多应用共享配置文件。
从nacos的客户端源码分析中可看到一些配置优先级的顺序。

原创不易，关注诚可贵，转发价更高！转载请注明出处，让我们互通有无，共同进步，欢迎沟通交流。

Java程序员博客系统推荐！我调研了100来个 Java 开源博客系统，发现这 5 个最好用！

Thu, 17 Sep 2020 10:53:34 CST

最近想倒腾一下博客，看了很多现成的比较成熟的开源博客系统，自己也简单从下面几个维度总结对比了一下：

star数量
技术选型
社区生态

当然啦！好东西不能独享。下面简单分享一下我所做的笔记。

欢迎小伙伴们评论区补充完善。ღ( ´･ᴗ･` )比心

halo

Github地址： github.com/halo-dev/ha…
Star : 16.2k
简介：✍ 一个优秀的开源博客发布应用。
技术：Spring Boot+JPA+Hutool
推荐等级：⭐⭐⭐⭐⭐
评价：这款博客生态非常好（可选主题也非常多），使用的人也非常多。并且！！ 还提供了小程序端！ 另外，搭建步骤也非常简单，基本是傻瓜式的。

Halo 首页：

Halo 主题仓库：

Halo 博客效果：

OneBlog

Github地址： gitee.com/yadong.zhan…
Star : 2.3k
简介：一个简洁美观、功能强大并且自适应的Java博客。使用Spring Boot开发，前端使用Bootstrap。支持移动端自适应，配有完备的前台和后台管理功能。
技术 : Springboot + Shiro + MySQL + Mybatis + Redis
推荐等级：⭐⭐⭐⭐
评价：我个人比较喜欢的一款博客样式类型（ 不过，需要花更多时间自定义和完善。没精力折腾的，慎入！），自带评论系统、SEO等功能。比较适合做知识沉淀类网站。

solo

Github地址： github.com/88250/solo
Star : 0.8k
简介： Solo 是一款小而美的开源博客系统，专为程序员设计。 Solo是B3log 分布式社区的 Java 博客端节点系统，欢迎加入下一代社区网络。
技术：Docker+H2+Nginx+ Latke （作者自研的以 JSON 为主的 Java Web 框架）
推荐等级：⭐⭐⭐⭐
评价：和 halo 一样，都是比较成熟的博客系统了，并且生态特别好。Solo 第一个版本是在 2020 年发布，到现在为止，Solo项目的作者已经维护这个项目快10年了。为你们点赞！感谢你们的付出！另外，需要格外说明一下： 项目框架不是选用的主流的 Spring Boot 而是作者自己写的一个叫做 Latke 的web 框架。

solo 博客效果：

蘑菇博客

Github地址： gitee.com/moxi159753/…
Star: 1.2k
简介：蘑菇博客(MoguBlog)，一个基于微服务架构的前后端分离博客系统。
技术：Spring Boot + Spring Cloud Alibaba + MyBatis-Plus + ElasticSearch
推荐等级：⭐⭐⭐⭐
评价：第一次看到基于微服务架构的个人博客系统。我觉得作者可能是为了检验自己对于微服务相关框架的掌握，正如作者说的那样：“现在挺多是SSM或者SSH的博客管理系统，想用spring boot + spring cloud + vue 的微服务架构进行尝试项目的构建，里面很多功能可能只是为了满足自己的学习需求而引入的，因此本博客也是一个非常好的SpringBoot、SpringCloud以及Vue技术的入门学习项目。”

蘑菇博客前台效果：

蘑菇博客后台效果：

plumemo

Github地址： github.com/byteblogs16…。
Star: 0.3k
简介：基于 SpringBoot实现零配置让系统的配置更简单，使用了 Mybatis-Plus快速开发框架，在不是复杂的查询操作下，无需写sql就可以快速完成接口编写。后台管理系统使用了vue中流行的 ant，另外前后交互使用了 JWT作为令牌，进行权限、登录校验。。
技术：Spring boot + MyBatis-Plus + JWT
推荐等级：⭐⭐⭐⭐
评价：界面简单美观，基于 Spring Boot 开发，适合用来学习，同时适合用来作为自己的博客。

plumemo博客后台效果：

以上就是我今天要推荐的所有博客了。花了比较长时间去搜索以及对比，希望能对JavaGuide的小可爱们的有帮助！ღ( ´･ᴗ･` )比心

如果有帮助的话，不要吝啬你们手中的在看和赞！“怼”起来！

以上 4 本优质 原创 PDF 微信搜“ JavaGuide”后台回复“ 面试突击”即可免费领取。

无代码开发，站到了程序员鄙视链顶端

Fri, 03 Apr 2020 19:06:59 CST

“无代码”不是在“淘汰”开发者，而是给予开发者更大挑战、更多机会。

疫情进一步推动了“无代码”行业的爆发。

微软称无代码是它的“Next Big Thing”，谷歌说无代码是下一代的变革和提升。也有越来越多的企业开始进入“无代码”领域。

这是在革开发者的命吗？你可能多虑了。

所谓“无代码”，并不是“不存在代码”，无代码平台的开发对后台的支撑能力提出了更高的要求，需要更为强大的技术团队。所以“无代码”不是在"淘汰”开发者，而是给予开发者更大挑战、更多机会。

只花72小时完成一个危机管理软件项目

新冠状病毒考验着政府处理危机的能力，纽约市以前所未有的速度创建了一个COVID-19危机管理软件平台，构建过程却没有编写任何计算机代码。

该平台由无代码初创公司Unqork建立，它的功能是绘制病毒地图，识别热点区域，并在居民与关键服务之间建立联系。Unqork的无代码软件让这座城市在72小时内上线该服务，而且只需使用可视化的拖放工具。

“信息就是力量，我们正在与时间赛跑，”纽约市信息技术与电信局局长Jessica Tisch在周三的一份新闻稿中指出，“为了对抗冠状病毒大流行，我们不仅需要更多的医疗设备和检测，还需要更多的实时数据。我们希望这个项目能成为一个标杆。”

这是一个值得注意的无代码软件应用场景。

“低代码”和“无代码”正在迅速成为科技和云巨头之间激烈竞争的一个领域。

谷歌云除了投资Unqork外，最近收购了AppSheet，这是“低代码”和“无代码”软件市场中最大的玩家之一，它让业务人员能够开发应用程序，而无需具备专门的编码技能。微软的一名高管告诉媒体，他预计，包括Power Platform在内的低代码软件将 成为主要的收入来源。市场上也一直有传言称AWS将推出一款名为“Amazon for Everyone”的产品。

巨头们已经开始激战

纽约市的案例是一次极其迅速的构建。Unqork首席营销官Schmelkin表示，一家金融服务公司过去需要花费数年时间才能完成的工作，如果采用“无代码”就可以在几个月内完成。他说：“在无代码情况下，少量的开发人员与业务人员聚在一起，三个月内就可以完成软件的全部开发。”而纽约市的这个平台只用了几天。

迄今为止，Unqork大约有100名程序员，主要致力于金融服务领域。但Unqork的雄心还延伸到了其他变化缓慢的行业，比如政府、医疗保健和房地产。它可以在所有三大云平台上运行——微软Azure、谷歌云和亚马逊网络服务，后者占据着云计算领域最大的市场份额。Schmelkin说，“我们将面对那些最顽固、最老派的行业，他们认为自己无法创新，因为遗留系统或大型机已经存在几十年了。”

现在大规模的数字化转型，如果仍然采用“老式”的编码方式，那是不可能实现的。低代码和无代码平台可以更快地构建新的应用程序，并允许企业内的非编码人员参与进来。

微软：未来5年将新增4.5亿个应用。

为了预测低代码和无代码软件在未来的重要性，微软曾简单计算了一下，认为未来5年将有4.5亿款新应用程序将被开发出来。这比过去40年里开发的所有应用程序都要多。

微软公司公民应用平台副总裁Charles Lamanna说：“如果这是真的，那么4.5亿款软件必须使用低代码工具。通过编写代码的话，没有那么多人能够那么快地构建出这么多软件。专业的开发人员应该专注于比费用提交表单或审批表单更困难的挑战。”

这位副总裁告诉媒体，他预计，包括Power Platform在内的低代码软件将 成为主要的收入来源。

微软CEO萨提亚也曾在一次公开场合谈论Power Platform，说微软是平台和生产力公司，这个平台将会是微软的“Next Big Thing”。微软的平台搭建从原来大家了解的Windows、Office 365、Azure，现在变成了Power Platform，这是一个重要的转变。

微软的Excel仍然需要用户使用一些公式，它就像一个初级的“低代码”软件，取代了数十年的数值计算。但Excel电子表格中这些流程，如果可以转移到Power App中，则又可以进一步提高效率。如果估计一下已经在使用Excel并可能迁移到新平台的用户数量，那会是一个相当大的一个数字！

Power Apps也是微软有史以来增长最快的商业应用程序。微软Lamanna表示：“主要是因为我们看到了市场上强劲的客户需求。”据一些第三方机构预测，Power Apps可能为微软带来100亿美元的营收，“但我们认为机会比这大。这是一个覆盖面相当之大的领域。”

谷歌：无代码是下一代的变革和提升

曾就职于Oracle的谷歌云总经理兼副总裁Amit Zavery说，在过去几十年里，许多技术供应商提供了被认为是“原型”的低代码/无代码软件。

“无代码允许你跨多个平台—— Oracle、 Salesforce和许多其他供应商——而不是被锁定到一个供应商。这就是其价值更高的地方，”Zavery说，“当与一家公司的产品捆绑在一起时，你无法创建功能强大的应用程序。”

无代码和低代码是有区别的。无代码软件只需要让员工接受几天的培训，虽然低代码软件对技术供应商来说仍然更容易构建，但无代码的产品集正在变大。

Zavery认为，世界将更加迅速地转向无代码。

被谷歌收购AppSheet已经在其平台上创建了 180万个应用。“在收购之前，我们就已经看到人们在AppSheet上做了很多工作，”Zavery说，“无代码是下一代的变革和提升。如果具备构建能力的话，大多数供应商都将专向无代码。并且每个云供应商都会在这个领域有所动作。”

亚马逊：AWS for Everyone

面对微软和谷歌在无代码上的行动，亚马逊将不得不对低代码和无代码做出回应。

“低代码”一词的创建者Rob Koplowitz说：“AWS需要自己开发一些东西，对所有这些公司来说，在培育大型合作伙伴生态系统方面，都需要谨慎行事。如果你在销售AppSheet，用户不希望被告知他们必须部署在谷歌云上。”他补充说，微软Azure是一个主要的玩家，谷歌收购AppSheet至少在一定程度上是对微软的回应。

“AWS for Everyone”产品负责人Adam Bosworth表示，他在亚马逊参与的这个项目“很快就会完成”，而且“其潜力堪比我所做过的任何一个项目”。

市场调查机构Forrester Research副总裁John Rymer说，最具发展潜力、每年增长100%的技术供应商都进入了低代码领域。“它规模庞大，增长非常快。并且在5年内增长了十倍。”

无代码给IT技术人带来的挑战

传统的软件开发需要编写数千行甚至高达几百万行的代码，然后对其进行调试，所以编程是一项复杂的工作。

低代码、无代码是一个将已有代码的可视化模块拖放到工作流中以创建应用程序的过程。它的优势在于：

速度快，在几天以内就可以交付项目。
降低了对开发人员的要求，项目可以更高效、以更低廉的成本完成。
一般会内置安全流程、数据集成、跨平台支持以及部署流程，用户可以将更多精力集中在业务逻辑的实现上。

所以随着低代码、无代码的出现，允许使用者不直接编写代码，让更多人自己去搭建一个网站、创作一个小程序商店、甚至搭建一个企业级业务流程管理系统。

无代码平台虽然能降低对用户的要求，但并不代表着能颠覆开发者。因为严格来说，并不存在无代码软件，任何软件都是必须有代码的。

低代码、无代码是让用户采用图像拖曳等更为人性化的人机交互方式实现编程，这就需要后台储备大量已编好的代码模块。无代码开发，对后台的支撑能力提出了更高的要求，后台需要配有非常强大的技术团队，来完成底层功能模块的开发工作。只有这样，才能让用户通过操作简洁的界面完成相应的“编程”工作。而且面对界面上的需求变化，对于开发人员来说，很可能是将之前的代码推翻重来。

无代码平台越来越多，对掌握底层技术的专家的需求也会越来越大。

谷歌云总经理兼副总裁Zavery说：“如果人们使用AppSheet在谷歌云上构建应用，那么用户量和数据量都会不断增加，所以我就需要更多的人来运行基础设施，保证它可以扩展。构建复杂应用程序的软件工程师仍然会继续存在。像Uber应用这样的技术不可能通过无代码来构建。”

北京理工大学计算机网络及对抗技术研究所所长闫怀志在回复新华网科技日报记者的提问时说道：“当前，无代码软件的开发效率可达到传统开发模式的10倍到30倍。但是，无代码开发绝不意味着，专业编程人员将失去饭碗。”

闫怀志认为，这是因为依靠无代码平台编制的软件，目前依旧存在一些不足。比如，要完成高效的无代码开发工作，操作者仍需掌握必要的软件开发知识和编程技能，而且这种软件的自定义能力会受到一定的限制，在可扩展性上也存在一些短板。同时，在安全性方面，无代码软件的安全性在很大程度上要依赖于平台自身架构的安全性及其提供的应用安全机制，因此在安全性方面，该种软件也是存在着一定的风险。

来自Forrester的Rymer也说，如果不首先建立适当的流程和基础设施，就把每个员工都变成应用开发人员是有风险的。各种各样的安全问题、合规性问题、系统集成问题都会出现，最后会产生一个个设计不当的应用。他知道有一家大型保险公司继承了16000个基于Quick Base的应用程序，而这些应用程序运行在Quick Base的一个退役版本上。Rymer说：“这是一个公司引入低代码却没有好好管理的例子，这是一个噩梦。那正是人们所害怕的。这将是一场混乱，业务人员在制造垃圾，而IT人员被迫提供支持。”

所以，“无代码”不是解放Coder，而是给Coder们提出了更高的要求、带来了更大的挑战。

参考链接 ：

Next frontier in Microsoft， Google， Amazon cloud battle is over a world without code

监听mysql的binlog日志工具分析：canal、Maxwell、Databus、DTS - 程序员大本营

Tue, 24 Mar 2020 08:37:45 CST

canal

定位：基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了mysql

原理：

canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议
mysql master收到dump请求，开始推送binary log给slave(也就是canal)
canal解析binary log对象(原始为byte流)

官网文档/源码（可谷歌右键翻译，有详细的接入案例）： https://github.com/alibaba/canal

网上好的学习链接：https://www.jianshu.com/p/6299048fad66

https://www.jianshu.com/p/6299048fad66

源码结构解析：http://www.tianshouzhi.com/api/tutorials/canal/380

偏日志解析的文章： https://blog.csdn.net/varyall/article/details/79208574

配置文件解析： https://blog.csdn.net/my201110lc/article/details/80765356

架构模型： https://blog.csdn.net/nuaazhaofeng/article/details/80513174

源码启动时序图： https://www.jianshu.com/p/d7d1b42242f1

parser

整个parser过程大致可分为几步：

    Connection获取上一次解析成功的位置（如果第一次启动，则获取初始制定的位置或者是当前数据库的binlog位点）
    Connection建立连接，发生BINLOG_DUMP命令
    Mysql开始推送Binary Log
    接收到的Binary Log通过Binlog parser进行协议解析，补充一些特定信息
    传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功
    存储成功后，定时记录Binary Log位置

sink

说明：

数据过滤：支持通配符的过滤模式，表名，字段内容等
数据路由/分发：解决1:n (1个parser对应多个store的模式)
数据归并：解决n:1 (多个parser对应1个store)
数据加工：在进入store之前进行额外的处理，比如join

Maxwell

官网：http://maxwells-daemon.io/

好的文章： https://blog.csdn.net/wwwdc1012/article/details/88388552

canal 由Java开发，分为服务端和客户端，拥有众多的衍生应用，性能稳定，功能强大；canal 需要自己编写客户端来消费canal解析到的数据。

maxwell相对于canal的优势是使用简单，它直接将数据变更输出为json字符串，不需要再编写客户端。

建议使用maxwell。

Databus

Databus是一种低延迟变化捕获系统，已成为LinkedIn数据处理管道不可或缺的一部分。Databus解决了可靠捕获，流动和处理主要数据更改的基本要求。Databus提供以下功能：

源与消费者之间的隔离
保证按顺序和至少一次交付具有高可用性
从更改流中的任意时间点开始消耗，包括整个数据的完全引导功能。
分区消费
源一致性保存

对比项		Databus	canal	结论
支持的数据库		mysql, oracle	mysql(据说内部版本支持oracle)	Databus目前支持的数据源更多
业务开发		业务只需要实现事件处理接口	事件处理外，需要处理ack/rollback，反序列化异常等	Databus开发接口用户友好度更高
服务模型	relay	relay可以同时服务多个client	一个server instance只能服务一个client （受限于server端保存拉取位点）	Databus服务模式更灵活
	client	client可以拉取多个relay的变更，访问的relay可以指定拉取某些表某些分片的变更	client只能从一个server拉取变更，而且只能是拉取全量的变更	Databus服务模式更灵活
可扩展性		client可以线性扩展，处理能力也能线性扩展（Databus可识别pk，自动做数据分片）	client无法扩展	Databus扩展性更好
可用性	client ha	client支持cluster模式，每个client处理一部分数据，某个client挂掉，其他client自动接管对应分片数据	主备client模式，主client消费，如果主client挂掉，备client可自动接管	Databus实时热备方案更成熟
	relay/server ha	多个relay可连接到同一个数据库， client可以配置多个relay，relay故障启动切换	主备relay模式，relay通过zk进行failover	canal主备模式对数据库影响更小
	故障对上游数据库的影响	client故障，bootstrap会继续拉取变更， client恢复后直接从bootstrap拉取历史变更	client故障会阻塞server拉取变更， client恢复会导致server瞬时从数据库拉取大量变更	Databus本身的故障对数据库影响几乎为0
系统状态监控		程序通过http接口将运行状态暴露给外部	暂无	Databus程序可监控性更好
开发语言		java，核心代码16w，测试代码6w	java，4.2w核心代码，6k测试代码	Databus项目更成熟，当然学习成本也更大

阿里云的数据传输服务DTS

数据传输服务（Data Transmission Service，简称DTS）是阿里云提供的一种支持 RDBMS（关系型数据库）、NoSQL、OLAP 等多种数据源之间数据交互的数据流服务。DTS提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输能力，可实现不停服数据迁移、数据异地灾备、异地多活(单元化)、跨境数据同步、实时数据仓库、查询报表分流、缓存更新、异步消息通知等多种业务应用场景，助您构建高安全、可扩展、高可用的数据架构。
           优势：数据传输（Data Transmission）服务 DTS 支持 RDBMS、NoSQL、OLAP 等多种数据源间的数据传输。它提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输方式。相对于第三方数据流工具，数据传输服务 DTS 提供更丰富多样、高性能、高安全可靠的传输链路，同时它提供了诸多便利功能，极大得方便了传输链路的创建及管理。
           个人理解：就是一个消息队列，会给你推送它包装过的sql对象，可以自己做个服务去解析这些sql对象。
           阿里文档快速入口：https://help.aliyun.com/product/26590.html

免去部署维护的昂贵使用成本。DTS针对阿里云RDS（在线关系型数据库）、DRDS等产品进行了适配，解决了Binlog日志回收，主备切换、VPC网络切换等场景下的订阅高可用问题。同时，针对RDS进行了针对性的性能优化。出于稳定性、性能及成本的考虑，推荐使用。

一个成功的程序员，自然要懂微服务，汇总微服务架构的15钟框架！

Tue, 10 Mar 2020 14:30:28 CST

这几年来，微服务这个概念越来越火了，火到什么程度呢？2019年有一个统计说，两千家企业里，45%在使用微服务，16%在实验开发和测试微服务架构，24%在学习微服务准备转型，只有剩下的15%的企业没有使用微服务。

微服务到底有什么好呢？微服务在2013年才被提出，短短几年就有这么快速的发展。微服务架构能够实现由小型自主服务组成一个整体应用，各个组成部分之间是松耦合的，复杂性低，各个部分可以独立部署，修复bug或者引入新特性更容易，能够独立扩展，不同技术栈之间可以使用不同框架、不同版本库甚至不同的操作系统平台。

对于中大型架构系统来说，微服务更加便捷，微服务成为很多企业架构重构的方向，同时也对架构师提出更高的挑战。目前有很多常用于微服务构建的框架，对于构建微服务架构能够带来一些帮助。

Java语言相关微服务框架

1.Spring Boot

Spring Boot的设计目的是简化新Spring应用初始搭建以及开发过程，2017年有64.4%的受访者决定使用Spring Boot，可以说是最受欢迎的微服务开发框架。利用Spring Boot开发的便捷度简化分布式系统基础设施的开发，比如像配置中心、注册、负载均衡等方面都可以做到一键启动和一键部署。

2.Spring Cloud

Spring Cloud是一个系列框架的合计，基于HTTP（s）的RETS服务构建服务体系，Spring Cloud能够帮助架构师构建一整套完整的微服务架构技术生态链。

3.Dubbo

Dubbo是由阿里巴巴开源的分布式服务化治理框架，通过RPC请求方式访问。Dubbo是在阿里巴巴的电商平台中逐渐探索演进所形成的，经历过复杂业务的高并发挑战，比Spring Cloud的开源时间还要早。目前阿里、京东、当当、携程、去哪等一些企业都在使用Dubbo。

4.Dropwizard

Dropwizard将Java生态系统中各个问题域里最好的组建集成于一身，能够快速打造一个Rest风格的后台，还可以整合Dropwizard核心以外的项目。国内现在使用Dropwizard还很少，资源也不多，但是与SpringBoot相比，Dropwizard在轻量化上更有优势，同时如果用过Spring，那么基本也会使用SpringBoot。

5.Akka

Akka是一个用Scala编写的库，可以用在有简化编写容错、高可伸缩性的Java和Scala的Actor模型，使用Akka能够实现微服务集群。

6.Vert.x/ Lagom/ ReactiveX/Spring 5

这四种框架主要用于响应式微服务开发，响应式本身和微服务没有关系，更多用于提升性能上，但是可以和微服务相结合，也可以提升性能。

.Net相关微服务框架

1. .NET Core

.NET Core是专门针对模块化微服务架构设计的，是跨平台应用程序开发框架，是微软开发的第一个官方版本。

2.Service Fabric

Service Fabric是微软开发的一个微服务框架，基于Service Fabric构建的很多云服务被用在了Azure上。

3.Surging

Surging是基于RPC协议的分布式微服务技术框架，基于.NET Core而来。

4.Microdot Framework

Microdot Framework用于编写定义服务逻辑代码，不需要解决开发分布式系统的挑战，能够很方便的进行MicrosoftOrleans集成。

Node.js相关微服务框架

1.Seneca

Seneca是Node.js的微服务框架开发工具，可以用于编写可用于产品环境的代码。

2.Hapi/ restify/ LoopBack

这三种框架的分工不同，前两种更适合开发简单的微服务后端系统，第三种更适合用在大型复杂应用开发，还可以用在现有微服务上的构建。

Go相关微服务框架

Go-Kit/Goa/Dubbogo

Go-Kit是分布式开发的工具合集，适合用于大型业务场景下构建微服务；Goa是用Go语言构建的微服务框架；Dubbogo是和阿里巴巴开源的Dubbo能够兼容的Golang微服务框架。

Python相关微服务框架

Python相关的微服务框架非常少，用的比较多的是Nameko。Nameko让实现微服务变得更简单，同时也提供了很丰富的功能，比如支持负载均衡、服务发现还支持依赖自动注入等，使用起来很方便，但是有限速、超时和权限机制不完善等缺点。

总结

微服务已经成为很多大型互联网公司的选择，对于架构师和想要成为架构师的工程师来说，掌握微服务不仅要学会使用相关框架来实现，还要掌握具体用法，在具体的实践中仍然要避开很多坑。

写在最后：

欢迎大家关注我新开通的公众号【 风平浪静如码】，海量Java相关文章，学习资料都会在里面更新，整理的资料也会放在里面。

觉得写的还不错的就点个赞，加个关注呗！点关注，不迷路，持续更新！！！

程序员需要了解的硬核知识之CPU

Mon, 21 Oct 2019 13:02:50 CST

大家都是程序员，大家都是和计算机打交道的程序员，大家都是和计算机中软件硬件打交道的程序员，大家都是和 CPU打交道的程序员，所以，不管你是玩儿硬件的还是做软件的，你的世界都少不了计算机最核心的 - CPU

CPU是什么

CPU 的全称是 Central Processing Unit，它是你的电脑中最 硬核的组件，这种说法一点不为过。CPU 是能够让你的计算机叫 计算机的核心组件，但是它却不能代表你的电脑，CPU 与计算机的关系就相当于大脑和人的关系。它是一种小型的计算机芯片，它嵌入在台式机、笔记本电脑或者平板电脑的主板上。通过在单个计算机芯片上放置数十亿个微型晶体管来构建 CPU。这些晶体管使它能够执行运行存储在系统内存中的程序所需的计算，也就是说 CPU 决定了你电脑的计算能力。

CPU 实际做什么

CPU 的核心是从程序或应用程序获取指令并执行计算。此过程可以分为三个关键阶段： 提取，解码和执行。CPU从系统的 RAM 中提取指令，然后解码该指令的实际内容，然后再由 CPU 的相关部分执行该指令。

RAM : 随机存取存储器（英语：Random Access Memory，缩写： RAM），也叫主存，是与 CPU 直接交换数据的内部存储器。它可以随时读写（刷新时除外），而且速度很快，通常作为操作系统或其他正在运行中的程序的 临时数据存储介质

CPU 的内部结构

说了这么多 CPU 的重要性，那么 CPU 的内部结构是什么呢？又是由什么组成的呢？下图展示了一般程序的运行流程（以 C 语言为例），可以说了解程序的运行流程是掌握程序运行机制的基础和前提。

在这个流程中，CPU 负责的就是解释和运行最终转换成机器语言的内容。

CPU 主要由两部分构成： 控制单元 和 算术逻辑单元（ALU）

控制单元：从内存中提取指令并解码执行
算数逻辑单元（ALU）：处理算数和逻辑运算

CPU 是计算机的心脏和大脑，它和内存都是由许多晶体管组成的电子部件。它接收数据输入，执行指令并处理信息。它与输入/输出（I / O）设备进行通信，这些设备向 CPU 发送数据和从 CPU 接收数据。

从功能来看，CPU 的内部由 寄存器、控制器、运算器和时钟四部分组成，各部分之间通过电信号连通。

寄存器是中央处理器内的组成部分。它们可以用来暂存指令、数据和地址。可以将其看作是内存的一种。根据种类的不同，一个 CPU 内部会有 20 - 100个寄存器。
控制器负责把内存上的指令、数据读入寄存器，并根据指令的结果控制计算机
运算器负责运算从内存中读入寄存器的数据
时钟 负责发出 CPU 开始计时的时钟信号

接下来简单解释一下内存，为什么说 CPU 需要讲一下内存呢，因为内存是与 CPU 进行沟通的桥梁。计算机所有程序的运行都是在内存中运行的，内存又被称为 主存，其作用是存放 CPU 中的运算数据，以及与硬盘等外部存储设备交换的数据。只要计算机在运行中，CPU 就会把需要运算的数据调到主存中进行运算，当运算完成后CPU再将结果传送出来，主存的运行也决定了计算机的稳定运行。

主存通过控制芯片与 CPU 进行相连，由可读写的元素构成，每个字节（1 byte = 8 bits）都带有一个地址编号， 注意是一个字节，而不是一个位。CPU 通过地址从主存中读取数据和指令，也可以根据地址写入数据。注意一点：当计算机关机时，内存中的指令和数据也会被清除。

CPU 是寄存器的集合体

在 CPU 的四个结构中，我们程序员只需要了解 寄存器就可以了，其余三个不用过多关注，为什么这么说？因为程序是把寄存器作为对象来描述的。

说到寄存器，就不得不说到汇编语言，我大学是学信息管理与信息系统的，我就没有学过汇编这门课（就算有这门课也不会好好学hhhh），出来混总是要还的，要想作为一个硬核程序员，不能不了解这些概念。说到汇编语言，就不得不说到高级语言，说到高级语言就不得不牵扯出 语言这个概念。

计算机语言

我们生而为人最明显的一个特征是我们能通过讲话来实现彼此的交流，但是计算机听不懂你说的话，你要想和他交流必须按照计算机指令来交换，这就涉及到语言的问题，计算机是由二进制构成的，它只能听的懂二进制也就是 机器语言，但是普通人是无法看懂机器语言的，这个时候就需要一种电脑既能识别，人又能理解的语言，最先出现的就是 汇编语言。但是汇编语言晦涩难懂，所以又出现了像是 C，C++，Java 的这种高级语言。

所以计算机语言一般分为两种：低级语言（机器语言，汇编语言）和高级语言。使用高级语言编写的程序，经过编译转换成机器语言后才能运行，而汇编语言经过汇编器才能转换为机器语言。

汇编语言

首先来看一段用汇编语言表示的代码清单

  mov eax, dword ptr [ebp-8]   /* 把数值从内存复制到 eax */
add eax, dword ptr [ebp-0Ch] /* 把 eax 的数值和内存的数值相加 */
mov dword ptr [ebp-4], eax /* 把 eax 的数值（上一步的结果）存储在内存中*/

这是采用汇编语言（assembly）编写程序的一部分。汇编语言采用 助记符(memonic) 来编写程序，每一个原本是电信号的机器语言指令会有一个与其对应的助记符，例如 mov,add 分别是数据的存储（move）和相加（addition）的简写。汇编语言和机器语言是一一对应的。这一点和高级语言有很大的不同，通常我们将汇编语言编写的程序转换为机器语言的过程称为 汇编；反之，机器语言转化为汇编语言的过程称为 反汇编。

汇编语言能够帮助你理解计算机做了什么工作，机器语言级别的程序是通过 寄存器来处理的，上面代码中的 eax,ebp 都是表示的寄存器，是 CPU 内部寄存器的名称，所以可以说 CPU 是一系列寄存器的集合体。在内存中的存储通过地址编号来表示，而寄存器的种类则通过名字来区分。

不同类型的 CPU ，其内部寄存器的种类，数量以及寄存器存储的数值范围都是不同的。不过，根据功能的不同，可以将寄存器划分为下面这几类

种类	功能
累加寄存器	存储运行的数据和运算后的数据。
标志寄存器	用于反应处理器的状态和运算结果的某些特征以及控制指令的执行。
程序计数器	程序计数器是用于存放下一条指令所在单元的地址的地方。
基址寄存器	存储数据内存的起始位置
变址寄存器	存储基址寄存器的相对地址
通用寄存器	存储任意数据
指令寄存器	储存正在被运行的指令，CPU内部使用，程序员无法对该寄存器进行读写
栈寄存器	存储栈区域的起始位置

其中 程序计数器、累加寄存器、标志寄存器、指令寄存器和栈寄存器都只有一个，其他寄存器一般有多个。

程序计数器

程序计数器(Program Counter)是用来存储下一条指令所在单元的地址。

程序执行时，PC的初值为程序第一条指令的地址，在顺序执行程序时， 控制器首先按程序计数器所指出的指令地址从内存中取出一条指令，然后分析和执行该指令，同时将PC的值加1指向下一条要执行的指令。

我们还是以一个事例为准来详细的看一下程序计数器的执行过程

这是一段进行相加的操作，程序启动，在经过编译解析后会由操作系统把硬盘中的程序复制到内存中，示例中的程序是将 123 和 456 执行相加操作，并将结果输出到显示器上。由于使用机器语言难以描述，所以这是经过翻译后的结果，实际上每个指令和数据都可能分布在不同的地址上，但为了方便说明，把组成一条指令的内存和数据放在了一个内存地址上。

地址 0100 是程序运行的起始位置。Windows 等操作系统把程序从硬盘复制到内存后，会将程序计数器作为设定为起始位置 0100，然后执行程序，每执行一条指令后，程序计数器的数值会增加1（或者直接指向下一条指令的地址），然后，CPU 就会根据程序计数器的数值，从内存中读取命令并执行，也就是说， 程序计数器控制着程序的流程。

条件分支和循环机制

我们都学过高级语言，高级语言中的条件控制流程主要分为三种： 顺序执行、条件分支、循环判断三种，顺序执行是按照地址的内容顺序的执行指令。条件分支是根据条件执行任意地址的指令。循环是重复执行同一地址的指令。

顺序执行的情况比较简单，每执行一条指令程序计数器的值就是 + 1。
条件和循环分支会使程序计数器的值指向任意的地址，这样一来，程序便可以返回到上一个地址来重复执行同一个指令，或者跳转到任意指令。

下面以条件分支为例来说明程序的执行过程（循环也很相似）

条件循环的执行流程

程序的开始过程和顺序流程是一样的，CPU 从0100处开始执行命令，在0100和0101都是顺序执行，PC 的值顺序+1，执行到0102地址的指令时，判断0106寄存器的数值大于0，跳转（jump）到0104地址的指令，将数值输出到显示器中，然后结束程序，0103 的指令被跳过了，这就和我们程序中的 if() 判断是一样的，在不满足条件的情况下，指令会直接跳过。所以 PC 的执行过程也就没有直接+1，而是下一条指令的地址。

标志寄存器

条件和循环分支会使用到 jump（跳转指令），会根据当前的指令来判断是否跳转，上面我们提到了 标志寄存器，无论当前累加寄存器的运算结果是正数、负数还是零，标志寄存器都会将其保存（也负责溢出和奇偶校验）

溢出（overflow）：是指运算的结果超过了寄存器的长度范围
奇偶校验（parity check）：是指检查运算结果的值是偶数还是奇数

CPU 在进行运算时，标志寄存器的数值会根据当前运算的结果自动设定，运算结果的正、负和零三种状态由标志寄存器的三个位表示。标志寄存器的第一个字节位、第二个字节位、第三个字节位各自的结果都为1时，分别代表着正数、零和负数。

CPU 的执行机制比较有意思，假设累加寄存器中存储的 XXX 和通用寄存器中存储的 YYY 做比较，执行比较的背后，CPU 的运算机制就会做减法运算。而无论减法运算的结果是正数、零还是负数，都会保存到标志寄存器中。结果为正表示 XXX 比 YYY 大，结果为零表示 XXX 和 YYY 相等，结果为负表示 XXX 比 YYY 小。程序比较的指令，实际上是在 CPU 内部做 减法运算。

函数调用机制

接下来，我们继续介绍函数调用机制，哪怕是高级语言编写的程序，函数调用处理也是通过把程序计数器的值设定成函数的存储地址来实现的。函数执行跳转指令后，必须进行返回处理，单纯的指令跳转没有意义，下面是一个实现函数跳转的例子

图中将变量 a 和 b 分别赋值为 123 和 456 ，调用 MyFun(a,b) 方法，进行指令跳转。图中的地址是将 C 语言编译成机器语言后运行时的地址，由于1行 C 程序在编译后通常会变为多行机器语言，所以图中的地址是分散的。在执行完 MyFun(a,b)指令后，程序会返回到 MyFun(a,b) 的下一条指令，CPU 继续执行下面的指令。

函数的调用和返回很重要的两个指令是 call 和 return 指令，再将函数的入口地址设定到程序计数器之前，call 指令会把调用函数后要执行的指令地址存储在名为栈的主存内。函数处理完毕后，再通过函数的出口来执行 return 指令。return 指令的功能是把保存在栈中的地址设定到程序计数器。MyFun 函数在被调用之前，0154 地址保存在栈中，MyFun 函数处理完成后，会把0154的地址保存在程序计数器中。这个调用过程如下

在一些高级语言的条件或者循环语句中，函数调用的处理会转换成 call 指令，函数结束后的处理则会转换成 return 指令。

通过地址和索引实现数组

接下来我们看一下基址寄存器和变址寄存器，通过这两个寄存器，我们可以对主存上的特定区域进行划分，来实现类似数组的操作，首先，我们用十六进制数将计算机内存上的 00000000 - FFFFFFFF 的地址划分出来。那么，凡是该范围的内存地址，只要有一个 32 位的寄存器，便可查看全部地址。但如果想要想数组那样分割特定的内存区域以达到连续查看的目的的话，使用两个寄存器会更加方便。

例如，我们用两个寄存器（基址寄存器和变址寄存器）来表示内存的值

这种表示方式很类似数组的构造， 数组是指同样长度的数据在内存中进行连续排列的数据构造。用数组名表示数组全部的值，通过索引来区分数组的各个数据元素，例如: a[0] - a[4]， []内的 0 - 4 就是数组的下标。

CPU 指令执行过程

那么 CPU 是如何执行一条条的指令的呢？

几乎所有的冯·诺伊曼型计算机的CPU，其工作都可以分为5个阶段： 取指令、指令译码、执行指令、访存取数、结果写回。

取指令阶段是将内存中的指令读取到 CPU 中寄存器的过程，程序寄存器用于存储下一条指令所在的地址
指令译码阶段，在取指令完成后，立马进入指令译码阶段，在指令译码阶段，指令译码器按照预定的指令格式，对取回的指令进行拆分和解释，识别区分出不同的指令类别以及各种获取操作数的方法。
执行指令阶段，译码完成后，就需要执行这一条指令了，此阶段的任务是完成指令所规定的各种操作，具体实现指令的功能。
访问取数阶段，根据指令的需要，有可能需要从内存中提取数据，此阶段的任务是：根据指令地址码，得到操作数在主存中的地址，并从主存中读取该操作数用于运算。
结果写回阶段，作为最后一个阶段，结果写回（Write Back，WB）阶段把执行指令阶段的运行结果数据“写回”到某种存储形式：结果数据经常被写到CPU的内部寄存器中，以便被后续的指令快速地存取；

总结

本篇文章我们主要讲述了

CPU 是什么，CPU 的重要性，CPU 执行程序的过程
还讲述了 CPU 的内部结构，它的组成部分
提到了汇编语言和高级语言
提到了CPU 与寄存器的关系
提到了主要的寄存器的功能，程序计数器，标志寄存器，基址寄存器和变址寄存器
还提到了函数调用机制是怎样的。
CPU 指令的执行过程

下面为自己做个宣传，欢迎关注公众号 Java建设者，号主是Java技术栈，热爱技术，喜欢阅读，热衷于分享和总结，希望能把每一篇好文章分享给成长道路上的你。我为你准备了百余种优质电子书和各种资源，相信你一定会喜欢并收藏的。

参考资料：

Central_processing_unit

《程序是怎样跑起来的》

秋招必备！不容错过的 github万星程序员面试宝典

Fri, 09 Aug 2019 16:00:00 CST

雷锋网 AI 开发者按，马上就是秋招啦，相信很多小伙伴现在都在紧张的泡图书馆备战和刷题。今天，我们要给大家推荐的是一份包含了阿里巴巴、华为、百度、腾讯、美团、字节跳动、滴滴、京东等知名互联网公司技术面试题的 github 项目。截止目前，该项目已获得 16000+ star。

项目的 github 地址为： https://github.com/0voice/interview_internal_reference

这份面试题库共分为 20 个篇章，其中，前面 8 篇（第一部分）是以公司为区分，总结了各大互联网公司的技术面试题和答案，后面部分（第二部分）是按照面试题的知识点进行了专题总结。

在第一部分，我们不仅可以看到这些知名互联网公司的面试题，还可以看到出题人和参考答案。以排在最前面的阿里巴巴为例子，我们可以看到，这里面收集了 37 个面试题。

上图的字比较小，为了方便大家阅读，我们把这些题目贴在下面：

阿里篇
________________________________________
1.1.1 如何实现一个高效的单向链表逆序输出？

1.1.2 已知 sqrt(2) 约等于 1.414，要求不用数学库，求 sqrt(2) 精确到小数点后 10 位

1.1.3 给定一个二叉搜索树 (BST)，找到树中第 K 小的节点

1.1.4 LRU 缓存机制

1.1.5 关于 epoll 和 select 的区别，以下哪些说法是正确的

1.1.6 从 innodb 的索引结构分析，为什么索引的 key 长度不能太长

1.1.7 MySQL 的数据如何恢复到任意时间点？

1.1.8 NFS 和 SMB 是最常见的两种 NAS（Network Attached Storage）协议，当把一个文件系统同时通过 NFS 和 SMB 协议共享给多个主机访问时，以下哪些说法是错误的

1.1.9 输入 ping IP 后敲回车，发包前会发生什么？

1.2.0 请解释下为什么鹿晗发布恋情的时候，微博系统会崩溃，如何解决？

1.2.1 现有一批邮件需要发送给订阅顾客，且有一个集群（集群的节点数不定，会动态扩容缩容）来负责具体的邮件发送任务，如何让系统尽快地完成发送？

1.2.2 有一批气象观测站，现需要获取这些站点的观测数据，并存储到 Hive 中。但是气象局只提供了 api 查询，每次只能查询单个观测点。那么如果能够方便快速地获取到所有的观测点的数据？

1.2.3 如何实现两金额数据相加（最多小数点两位）

1.2.4 关于并行计算的一些基础开放问题

1.2.5 请计算 XILINX 公司 VU9P 芯片的算力相当于多少 TOPS，给出计算过程与公式

1.2.6 一颗现代处理器，每秒大概可以执行多少条简单的 MOV 指令，有哪些主要的影响因素

1.2.7 请分析 MaxCompute 产品与分布式技术的关系、当前大数据计算平台类产品的市场现状和发展趋势

1.2.8 对大数据平台中的元数据管理是怎么理解的，元数据收集管理体系是怎么样的，会对大数据应用有什么样的影响

1.2.9 你理解常见如阿里，和友商大数据平台的技术体系差异以及发展趋势和技术瓶颈，在存储和计算两个方面进行概述

1.3.0 在云计算大数据处理场景中，每天运行着成千上万的任务，每个任务都要进行 IO 读写。存储系统为了更好的服务，经常会保证高优先级的任务优先执行。当多个作业或用户访问存储系统时, 如何保证优先级和公平性

1.3.1 最大频率栈

1.3.2 给定一个链表，删除链表的倒数第 N 个节点，并且返回链表的头结点

1.3.3 如果让你设计一个通用的、支持各种数据库秒级备份和恢复的系统，你会如何设计

1.3.4 如果让你来设计一个支持数据库、NOSQL 和大数据之间数据实时流动的数据流及处理的系统，你会考虑哪些问题？如何设计？

1.3.5 给定一个整数数组和一个整数，返回两个数组的索引，这两个索引指向的数字的加和等于指定的整数。需要最优的算法，分析算法的空间和时间复杂度

1.3.6 假如给你一个新产品，你将从哪些方面来保障它的质量？

1.3.7 请评估一下程序的执行结果？

打开这些面试题，我们可以看到出题人和参考答案。如打开第一题：「如何实现一个高效的单向链表逆序输出？」我们看到的内容如下：

问题：如何实现一个高效的单向链表逆序输出？

出题人：阿里巴巴出题专家：昀龙／阿里云弹性人工智能负责人

参考答案：下面是其中一种写法，也可以有不同的写法，比如递归等。供参考。

typedef struct node{

    int data;

struct node* next;

   node(int d):data(d), next(NULL){}

    }node;

void reverse(node* head)

{

    if(NULL == head || NULL == head->next){

        return;

}

    node* prev=NULL;

    node* pcur=head->next;

    node* next;

    while(pcur!=NULL){

   if(pcur->next==NULL){

            pcur->next=prev;

            break;

        }

        next=pcur->next;

        pcur->next=prev;

        prev=pcur;

        pcur=next;

    }

    head->next=pcur;

    node*tmp=head->next;

    while(tmp!=NULL){

        cout<<tmp->data<<"\t";

        tmp=tmp->next;

    }

}

第二部分分为了 12 个技术专题，分别是 MySQL 篇、Redis 篇、MongDB 篇、Zookeeper 篇、Nginx 篇、算法篇、内存篇、cpu 篇、磁盘篇、网络通信篇、安全篇和并发篇。这里面针对每个专题，整理了一些经常会遇到的面试题。

例如，MySQL 篇包含的题目如下：

和前面一样，这里也给出了参考答案。打开上图的第一个题目，我们看到如下内容：

题目：主键超键候选键外键是什么

定义

超键 (super key): 在关系中能唯一标识元组的属性集称为关系模式的超键

候选键 (candidate key): 不含有多余属性的超键称为候选键。也就是在候选键中，若再删除属性，就不是键了！

主键 (primary key): 用户选作元组标识的一个候选键程序主键

外键 (foreign key)：如果关系模式 R 中属性 K 是其它模式的主键，那么 k 在模式 R 中称为外键。

举例

比如有如下数据：

学号	姓名	性别	年龄	系别	专业
20020612	李辉	男	20	计算机	软件开发
20060613	张明	男	18	计算机	软件开发
20060614	王小玉	女	19	物理	力学
20060615	李淑华	女	17	生物	动物学
20060616	赵静	男	21	化学	食品化学
20060617	赵静	女	20	生物	植物学

1.超键

在关系中能唯一标识元组的属性集称为关系模式的超键。

于是我们从例子中可以发现学号是标识学生实体的唯一标识。那么该元组的超键就为学号。

除此之外我们还可以把它跟其他属性组合起来，比如：

(学号，性别)

(学号，年龄)

这样也是超键。

2.候选键

不含多余属性的超键为候选键。

根据例子可知，学号是一个可以唯一标识元组的唯一标识，因此学号是一个候选键，实际上，候选键是超键的子集，比如（学号，年龄）是超键，但是它不是候选键。因为它还有了额外的属性。

3.主键

用户选择的候选键作为该元组的唯一标识，那么它就为主键。

简单的说，例子中的元组的候选键为学号，但是我们选定他作为该元组的唯一标识，那么学号就为主键。

4.外键

外键是相对于主键的，比如在学生记录里，主键为学号，在成绩单表中也有学号字段，因此学号为成绩单表的外键，为学生表的主键。

总结

主键为候选键的子集，候选键为超键的子集，而外键的确定是相对于主键的。

虽然这只是一个非常简单的概念题，但由此我们也可以看到，这份题库给出的答案特别非常详细，不仅对问题中提出的概念进行了解释，还用具体的例子进行了说明，方便同学们的容易理解和记忆。

还在等什么，赶快收藏这份资源开始学习吧~一分耕耘一分收获，相信同学们接下来一定会拿到心仪的 offer，加油！

雷锋网雷锋网雷锋网

数学对程序员来说真的很重要吗？

Mon, 05 Aug 2019 00:00:00 CST

在本站搜索一下，就有很多结果的哦：

《冒号课堂》----答读者问(1)——对程序员的一些个人建议

http://blog.zhenghui.org/2010/06/03/advice-on-programmer/

关于数学基础，窃以为并非什么太大的问题。几乎每个得知我数学背景的人都会对我说：哦，学数学的人来学计算机自然容易啦。事实上，这种观点虽然极为普遍，但也极为肤浅。本人从事数学 14 年（从本科算起）、从事计算机 12 年（与前者有部分重合），在这一点上还是比较有发言权的。事先说明，以下提到的数学不包括高中数学。其实大多数从事软件开发的人员用不到太多的数学知识，他们只需要正常的逻辑思维能力和抽象思维能力。整天拿数学说事，要么是无知，要么是找借口，要么是装高深。当然，我不否认一些高级算法、计算机理论以及人工智能等领域可能涉及到高深的数学知识（其实也只是图论、组合数学、数论、概率论、计算几何、抽象代数、数学逻辑等中的一小部分），但那毕竟只是少数。我也不否认自己的数学背景有助于对编程的理解，但投入产出比太低，不值得作为经验来推广。不过若想成为一位计算机科学家，那就另作别论了——这时数学懂得再多也会嫌少的。

倒是英语我希望你更重视些。我在《冒号课堂》中专门提过阅读原著的必要性，而且你也意识到译著的质量问题。建议不必特地去学习英语（你本来就会了，不是吗？），只要坚持读经典原著即可。其实，计算机方面的英文算是很容易的了，关键是克服自己的惯性和惰性。开始可能不习惯，看多了就习惯了。在此提醒一点，在阅读时请有意识地培养自己对英语的语感，就像编程时要有意识地培养自己对编程语言的语感一样。

总之，对于程序员来说，数学没有人们认为的那么重要，英语没有人们认为的那么不重要。

再说说专业方面的问题。你提到愿意重新自学大学课程，虽精神可嘉，但未必可取。从软件（或建筑）设计的观点来看，这是 bottom-up 法。作为学生，最好采用这种方法，但你已经参加工作了，所以我建议你更多地采用 top-down 法。这当然不是轻视基础知识，而是认为获取知识最高效的方法莫过于按需（ on demand ）学习。在实际工作中意识到某个知识点的重要性，从而有针对性地弥补短板，这样学习起来不仅更有效率，也更有兴味。需要强调的是，绝不能只是 “头痛医头”，而要“拔萝卜带出泥”。只有寻根究底、以点带面，才能快速有效地建立起自己的知识结构体系。对于软件开发这类实践性很强的专业来说，该法尤其奏效。

程序员应该怎样提高自己

Wed, 24 Jul 2019 16:51:37 CST

经常有小（我 20 岁左右的）朋友问我，作为一个程序员该怎样提高自己。每个人的经历不同，所处环境不错，其实这个问题很难具体回答。不如好好写一篇总结，以后就不必每封 email 都重新写一次了。

纵观我近 30 年的编程生涯，在每个时期，我看到的东西都不同。想必再过 10 年还会有变迁。我只能写写当下眼界所及之处。

引我爱上编程，并乐此不疲的学习，是“我能写出更高效的代码”这种乐趣。如果一个人在学习编程开始，不努力让自己的代码变得更高效，发现不了优化的乐趣，我想他很难爱上编程。Don Knuth 说，Premature optimization is the root of all evil ，这句话背后的道理，不必一开始就强行接受。evil 最能蛊惑人心，但是我们需要它引入门。

朝着优化这条路走下去，你会有自发的动力去了解计算机的本质架构，理解操作系统，理解内存模型，理解新的软硬件技术（它们大多数都是为了让程序跑的更快而发明出来）。否则，现在去学习这些东西，并不会体会到现实的意义。软件开发在今天，大部分的工作都在很高的层次了，大部分人的日常都在完成一些琐碎的业务，用不到这些。但实际上，你在融汇贯通后，可以在很高的层面凭经验就能从蛛丝马迹判断出底层发生的问题；可以从一些代码片段，判断出整个模块的设计意义。这些是无法作为单独的技能学会的。

精通一门语言是最基本的要求。所谓精通，就是要了解这门语言的各种阴暗角落。用每一样语言特性的背后的代价。知道在面临各种问题时用这门语言解决该问题的惯用法。大部分通用语言都会有设计缺陷，表现在具体方面就是面对某些问题，写起来直接了当，而另一类问题时却要绕很多弯弯，这些绕弯弯的部分就需要用某种模式去弥补。我认为，所谓编程的设计模式，并不是跨语言而独立存在的，它们是强烈依附于编程语言的。《设计模式》这本书，我读过的版本是基于 C++ 的，设计模式被谈论的更多的是在 Java 社区。这类模式都有很深的语言烙印。我们学习设计模式其实学的就是一门语言的惯用法。

初次学习设计模式时，肯定会有豁然开朗的感觉。但不应把自己陷入其中。为了提高一次层次，就必须精通至少第二门的语言。我的第一语言是 C ，第二语言是 Lua 。但对于许多人，肯定会有很多更好的选择。多看看不同的语言下解决问题的不同方式，有助于提高编程技能。

在我谈论程序员的编程技能的时候，我指的通常是两类能力：一是运用熟悉的编程语言，用在该语言下最高效的方法解决需求的能力；二是领域知识，尽量多的了解工作所处领域前人的积累，已存在的软件层次的接口，接口背后的代价。这两者缺一不可。不要用自己学习能力强为借口，认为随时可以进入一个新语言，一个新领域，而不会比别人差。不管是一门语言的使用，还是对一个领域的了解，都是需要长期的实践刻意积累的。

以上，都是我认为一个程序员对自己最基本的要求。这些东西多么精进都不为过。但还有一些更高层面的东西。

那就是分解问题，保持简洁的能力。也可以说是规划和构架的能力。这是超出编程语言，具体问题领域的，不过绝不能绕开它们。如果一个程序员编码很粗糙，或是对所在领域一知半解，我绝对不会信任他做的设计。

Keep It Simple, Stupid 谁都会说，但不受优化的蛊惑，我觉得很难。因为完全对优化代码免疫的人，我觉得他很难成为一名优秀的程序员。迈不过第一步，就谈不上在下一步有什么成就。大部分软件问题，本质上都是怎么把复杂问题分层次，分模块，化繁为简的过程。底层开发、基础设施建设为什么吸引了很多自命热爱编程的人，不是因为它们有挑战，相反，它们更纯粹，更简单，更容易做取舍。精益求精的人更容易做出成绩。

带着把各方各面都做到精益求精的心，跨越多个层次去看整个问题。奉着此心做取舍，知道封装和简化带来的代价，随时审视代价到底值不值。我很难总结出教条，这似乎真的只能用个人品味去解释：为什么这里要保持更朴素的数据结构，而牺牲高效的算法；那里为了少定义一个 api ，却让一件简单的任务变得更繁琐。

另一方面，规划不仅仅是针对代码，也包括了开发过程的一切。你不仅需要规划问题怎样划分，还要规划每个部分花多少时间和精力，区分轻重缓急。顺便谈谈超时工作的问题，我在前段谈 996 的时候就写过，超时工作其实反映的是规划的失误。找到正确的方法做事，最终需要投入的人力能有 10，100 倍的差距；而延长工作时间却无法超过 3 倍工时。提高自己的规划能力，应该先尽力减少超时工作。

前段时间有人问我，现在让你去面试程序员，你会考察些什么。我想了想，最近几年，我越发的不会做面试了。越来越不喜欢用具体技术问题考验面试者。

相比编写代码、调试代码、阅读代码、这些硬能力；我可能更为看重对各类工具掌握的软能力。比如有些人对 C++ 的犄角旮旯了解的一清二楚，却对 C++ 编译器的命令行参数一知半解，只会使用 IDE 开发，我觉得这样的技术栈是非常畸形的。软件的构建流程绝不仅仅是写好代码，就全部交给自动化工具去完成。即使仅局限于写代码，那么用代码生成代码，设计 DSL 解决领域问题，也是必备技能。这些在 meta 层面解决问题的方式，离不开你对构建工具的了解。

我们在日常工作中面临的很多琐碎，大部分都有现成的工具解放你的时间。分析日志，加工数据、收集信息，等等。都有很多途径去做。有笨拙的手工方法，有工具语言方便你编写脚本批处理，有现成的工具待你去发掘学习。看看你的工具箱里是不是只有一把锤子？

开源逐渐成为主流，我认为是现代软件开发方式的重大变迁。程序员群体可能是为数不多的，顶尖个体的生产力能够百倍千余于平均水平的人群了。世界范围的开源开发，使得最顶尖的人可以把精力聚焦在不同的点，极大的放大他们的价值。所以造轮子固然有趣，会用轮子却更为重要。但大多数情况下，我们不能像搭乐高积木一样的组装软件――虽然那一定是每个开源模块的努力方向――理解和沟通的能力就显得格外重要。

有一段时间我在招聘应届毕业生时甚至觉得，考察写的代码好不好一点都不重要。真不如看看他写的文章，写的东西简单还是复杂不重要，就看有没有能力把事情说清楚。

在开源的世界中，不是你有能力读懂别人的代码就够了。如果你想使用，就必然面临你特有的需求，也有极大的可能性遇到别人没有遇到的问题。和作者沟通，和开发社区建立起良好的关系，说服维护者按你的想法推进这个软件的发展，或是吸纳别人的想法修正自己的设计，这是非常重要的技能。而弄个 fork 自己随心所欲的修改，甚至重起炉灶自造轮子，自己的层次就很难进一步突破了。

谈到这里，不得不提的是， git 绝对是软件行业近二十年最伟大的发明之一。它值得每个程序员正儿八经的学习，绝不应满足于会 commit push pull 就够了。它是进入开源世界的敲门砖。一个能力超强的程序员，如果不融入同样顶尖的团体，就是在浪费自己的人生。

我用了10年从深圳流水线厂妹做到纽约高薪程序员

Sun, 16 Jun 2019 07:50:05 CST

孙玲每天早上从纽约布鲁克林的居室出发，一头扎进地铁，一个小时后，她出现在繁忙的曼哈顿街头，最终目的地是位于切尔西区第八大道上的谷歌办公大楼。

孙玲目前是EPAM Systems公司的一名程序员，负责公司的谷歌合作业务，办公地点在谷歌纽约总部，当被问及十年前是否想象过自己有一天能与全球顶尖程序员共事时，她坦言：“即使在一年前，我都没有想象过现在能在谷歌上班”。

△孙玲与家人们在家门口的合影。

孙玲来自湖南娄底的一个农村家庭，爸爸曾是木工，后来在机器化进程中被淘汰，妈妈会踩缝纫机，但在农村找不到合适的工作，家境比较困难。孙玲的哥哥与她读同年级，小学毕业后，哥哥宁可跪在雪地里也不愿意去读初中，谁也劝不动。虽然孙玲心里想继续读书，但她父亲看到哥哥如此抗拒读书，也让她一起停学了。

停学后，她跟舅舅学了三个月理发，第一次剪发剪坏了，只能将客人的头剃光才能修复发型，便没有兴趣继续学下去，只好放弃。之后，她回家跟着父母拿锄头下地干农活。务农每天要消耗大量体力，太辛苦，她还是想回到学校学习。一年后，在孙玲的要求下，父母同意她复学，中考考上了县城排名第三的高中。

△ 孙玲（第一排左4）的高中毕业合影。

在孙玲从小长大的村子里，能念完高中就已经是很不错的学生了，上大学的人更是少得可怜。大多数人在初高中毕业后，会跟随亲戚朋友外出打工，或者做点小生意。孙玲的父亲觉得“读那么多书也没用，念完初中就可以了”，这在她看来是“典型的传统农民思想”。

△ 孙玲家乡的田野，几个孩子在玩耍。

那年八月，正是稻谷收割的农忙时节，孙玲因为帮忙务农错过了入学日期。一心想着去城里读书的她有点着急，公立中学因错过入学不能去读，家人只好帮她在县城找了一所民办高中勉强入学。那所高中主要接收高考复读生，教师水平参差不齐，“读的都是些死书”。

2009年6月，孙玲是高考大军中并不起眼的一员，最后以399分的成绩在学校的应届生中排名第一，尽管这样，还是够不着二本分数线。当她回忆起十年前的高考，“当时不觉得紧张，也意识不到高考有多重要，高中时状态很压抑，只想着早点考完就能轻松一点。尽管认真去读了，但书就是读不好，考试也尽全力去考了，还是有很多题不会。”高考后的那个夏天，她在堂哥的介绍下，去往深圳的工厂打工。

△ 孙玲在家乡的池塘边钓鱼。

2009年7月21日，孙玲清楚地记得那一天，她与一位同班同学结伴，坐了14个小时的绿皮火车抵达深圳西站。下了火车又坐上公交，从前只在电视上见过深圳的高楼大厦活现在她眼前，但因为晕车，她根本无心观察窗外的城市景观，最后昏昏沉沉地到了堂哥工作的工厂。

孙玲最初在电池厂上班，负责电池正负极的检测。她被安排上晚班，需要强行颠倒生物钟。工厂环境封闭，甚至都没有一扇窗，夜晚和黎明的更替，多数时候让人浑然不觉。在19岁的孙玲看来，工厂像个巨大的齿轮，轮转不歇。一天12个小时重复做着不喜欢的事情，她确信这不是她想要的生活，“现实和想象完全是天差地别，那时生活极其单调，没有丝毫价值感，在外面所有事情都要靠自己，一切都没有想象中那么简单”。孙玲在工厂做了几个月就想“逃离”，她想去学点什么、做点什么，跳脱出那个并不属于她的环境。

△ 孙玲在谷歌的办公桌。

孙玲想起了计算机。高考结束后的暑假，一个软件培训机构在学校推广七天免费夏令营，她那时对“计算机”没什么概念，“民办高中根本没有电脑课，印象中我只去过两三次网吧，当时对电脑一无所知”。在好奇心的驱使下，孙玲报了名，具体过程她已记不大清，只记得最后一天PPT展示时，“感觉电脑很神奇，可以做出这么漂亮的东西”。

孙玲形容自己的好奇心时，喜欢用“种子”这个词，夏令营时得到的那颗好奇心的种子一直被孙玲揣在兜里，在乏味的流水线生活中偶然翻看，恍然醒悟。闲暇时，她开始到培训机构咨询软件培训，在敲定了一个最合适的课程后，2010年5月，月薪只有2300元的她省吃俭用攒够第一期的8000元学费，从工厂辞职了。后面的将近500个日夜是孙玲漫长的“蛰伏期”，她从深圳龙华的工厂来到福田区学习，两家培训机构、三期软件课程、三份勉强够生活的零工、一张额度为3000元的信用卡，这些几乎构成了孙玲那一年多来生活的全部。那段时间，她不在上课就在打工，或是在去两者的路上。

△ 2012年，公司团建，她跟着去了广州的长隆欢乐世界。

孙玲提起那时的生活，满足似乎大于抱怨，“比在工厂时过得充实很多，每天都在学东西，当时觉得学习能改变现状，能让我多一点选择”。在她经济捉襟见肘的时候，爸爸默默帮她付了培训机构的首付学费；那个陪她坐14个小时绿皮车到深圳的朋友，那几年做销售风生水起，时常请她吃大餐，“她用这种方式来犒劳我”。

△ 孙玲在一家与政府合作的技术公司上班时的办公桌。

孙玲完成培训顺利毕业后，2011年，她在IT行业找到了工作，那是一家与政府合作的技术公司，她负责为深圳公务员计算工资，转正后月薪4000元。为了省钱，她与高中同学合租在郊区，房租每月400元。

从高中毕业的时候开始，她心里就有一个“白领梦”，希望拥有一台自己的电脑，在一个有窗户的办公室里工作。那一次，她终于实现了，与电脑打交道，周末双休，拿稳定的薪水，这一切全都符合她对理想工作的期许。第一次走进办公室，坐在电脑对面，看着屏幕上倒映的自己的面孔时，孙玲知道自己再也不会回到车间流水线了，生活慢慢开始走上正轨，“两年来所有的艰苦都值得”。

△ 孙玲在玩飞盘前，躺在草坪上复习雅思。

2014年对孙玲来说有点特别，那一年，世界以高倍速纷繁地展现在她的面前。回忆起来，14年孙玲大概有种“很漂亮地打了一局游戏”的畅快感，自考三下两下被拿下，薪水也在跳槽后翻倍增长，工作之余玩飞盘、学英语，坚持跑步，这些过程中藏着许多不期而遇的小惊喜。

工作稳定下来之后，孙玲想继续刷一下学历，先是报了西安交通大学计算机专业远程教育课程，拿到了大专文凭，后来又利用一年半的周末学习完成了深圳大学的专升本课程。一边工作一边学习几乎可以说是孙玲生活的常态，无论经济紧张还是宽裕，孙玲磕磕绊绊的求学路始终不曾中断。她保持着清醒的自谦，“我还是一个普通人，还是一个农村的孩子”，也坦承“不断学习让我有能力更好地去体验这个世界，去探索更多的未知”。

△ 2016年，孙玲（左2）在深圳参加飞盘赛事。

2014年6月，孙玲偶然当了一场英语公益活动的志愿者，认识了现场的外国主持人，还被拉进了一个群，群里的人给孙玲介绍关于飞盘运动的知识，令她渐渐对玩飞盘产生了浓厚的兴趣。

△ 孙玲与一起玩飞盘的好朋友Sonia，她们互换了洞洞鞋穿。

△ 孙玲（第二排右2）与深圳飞盘队友。

工作之余，她开始四处去参加飞盘比赛，将国内各个城市和一些东南亚国家都借着比赛的名义玩了一圈，结识了不少朋友，在孙玲看来，“身边的人英语都说得很溜，很优秀，经历也不一般，而我只是一个普普通通的程序员，跟他们比起来，感觉自己很逊色。”

△ 孙玲与玩飞盘认识的朋友台湾姐姐Kay（右1）和Ada。

2016年圣诞节，朋友们拉她去参加派对，大家喝了点酒，心愿越说越多，孙玲拿了一张小卡片，在上面写下“希望可以去国外工作或者生活一年”，然后将卡片挂在圣诞树上，“当时没有想那么多，只是想到国外可以练习英语，也想经历更多，给自己增加人生体验”。

△ 孙玲在优胜美地国家公园。

那是一则平淡无奇的招聘广告。一所美国学校，招赴美带薪实习的程序员，八到九个月的学习期，一年的实习期，要求有工作经验、有本科学位、有一定的英语能力、有第一期首付的学费和生活费。孙玲在招聘网站上划过了无数信息，这一条，她没有错过。

△ 孙玲在美国的宿舍。

孙玲决定为它努力一把，“因为有这么一个机会，我真的很想抓住”。从2017年1月到9月，她的生活几乎全部围绕着英语和钱展开， 5月雅思考到了5.5分，当时月薪已经过万的她终于在9月份来临前存到了12万，磕磕绊绊拿到学校的offer。

△ 孙玲与美国的同学们。

当拿到签证走出使馆门那刻，孙玲想到了电影《当幸福来敲门》中的一幕，男主角Chris面试成功后，走在人群中，所有人都一脸冷漠地机械地向前移动，他控制不了自己的喜悦，把手举过头顶击掌。“我那一刻的心情和Chris类似，没有语言可以描述，实在是太激动了。”不久后，飞机穿越云层和晨昏，把孙玲从东八区带到了西五区。

△ 孙玲所在大学的食堂。

孙玲所在的学校在美国爱荷华州的小镇上，人不多，安静得仿佛与世隔绝。九个月的学习期，需要每月学习一门课程，上午学理论，下午练实操。

△ 学校的项目小组成员在分析讨论。

让她印象最深的是一门关于大数据的课程，她的结课作业做了Facebook的数据分析，找出使用者的常用字以及点赞最多的人，再将数据视觉化。“我发现这个项目可以用来研究我身边同学们的Facebook的状态，很有意思。”

△ 孙玲学校周边的湖，她常在这里跑步。

学习期间结束后，孙玲开始找工作。为了寻找更多的工作机会，她搬到了靠近硅谷的加州。孙玲给自己定了个三个月的期限，她坦言，压力真的很大，三个月如果找不到工作，她就必须回学校再去上课，找不到工作就没有收入，也意味着还不起学费的贷款。生活的严酷逻辑环环相扣，孙玲那时就清醒地意识到，自己没有回转的余地。

△ 孙玲（前排右1）参加纽约感恩节飞盘赛事。

美国慢悠悠的找工作流程一开始让孙玲有点着急，“投完简历就开始等着，先是邮件沟通，第一次安排面试会给你打电话通知，接着去参加面试，再等一个星期，才会收到回复”。除了投简历、接电话的时候，孙玲基本都在刷算法题。

两个月，经历了将近60场面试之后，Epam Systems公司向她抛来橄榄枝，雇佣她作为与谷歌对接的程序员，在谷歌总部办公，年薪高达9万至13万美金，足够她慢慢还清学费。面试过程被她描述得很轻盈，“HR简单问了一下我的工作经验，觉得OK，就安排公司的技术面试，接着是谷歌的技术面试，周期大概一个月”，“其实也没有特别困难，因为机会真的很多”。

△ Google楼外景

正式在谷歌上班的那天傍晚，孙玲独自把谷歌大楼一层层逛了一遍，八楼的天台上，晚风沉醉，望着远处灯光渐次亮起的曼哈顿CBD，孙玲的心思有些飘忽，在社会这所大学里，十年的野蛮生长，好似一场梦。

△ 孙玲在谷歌办公室。

在谷歌工作，没有固定上下班时间，可以选择在家办公，多数时间可以自己控制，即使不在座位上，只要工作完成即可，也很少会加班。

△ Google办公室

△ 孙玲（右1）与朋友们骑行环绕曼哈顿。

下午五点，办公室的人几乎全部走完，孙玲也因此有很多自己的时间。工作之余她坚持玩飞盘，时不时跑马拉松，骑行环绕曼哈顿，在周末参加算法学习小组。为了让自己更擅长与人打交道，她强迫自己走出舒适区，走上街头，对陌生人进行采访，剪辑制作成视频，分享纽约街头陌生人的故事。

△ 孙玲在采访陌生人。

孙玲喜欢纽约，但不确定是否会长期扎根于此，即将来到“而立之年”，她似乎没有什么年龄的焦虑。孙玲也说不清未来的具体面貌，她想做的只是一头扎进未知，在这个好玩的世界四处探险的小孩子。

她最近在看《自控力》这本书，因为想成为一个高效学习者，“保持open mind，这大概是我人生的一个关键词，不断学习，接触的东西越多，人会具有更大的包容性，思考问题的角度和看待问题的方式也更多”。

作者 | 羽祺

编辑 | 图拉

实习生 | 匡若彤

- END -

给我好看👇

外企程序员的黑暗时刻

Sun, 19 May 2019 07:07:30 CST

本文来自全天候科技，阅读更多请登陆 www.awtmt.com或华尔街见闻APP。

作者|杨凡编辑|罗丽娟

“北京最大的一个养老院倒了。” 甲骨文北京研发中心突然裁员500多人的情形被外界这样调侃。

入职甲骨文快三年的刘楠一直觉得自己不会经历这样的黑暗时刻，毕竟在这之前，一切都显得较为乐观。身居甲骨文目前重点发力的云计算业务团队，刘楠看着自己部门在近几年迅速扩张，发展势头良好。直到被HR叫去一对一谈话，刘楠才意识到自己真的被裁掉了。

2019年5月7日，美国巨头企业甲骨文宣布将在中国大规模裁员，首次裁员人数在900人左右，中国各个甲骨文研发城市均有涉及，其中北京被裁人员最多，超过500人。本次裁员风波后，甲骨文中国研发中心将关闭。

数十年前，国际科技巨头们以传统IT行业先发优势进入中国，并将其完善的公司运营管理体系引入，由此在中国培养起了一批技术人才。近年来，随着国内互联网企业的迅速成长，“年轻”、“创新”、“适应高强度加班”成为了国内互联网技术人才的必备条件。相比之下，外企的技术人员的工作节奏显得格外“养尊处优”。

甲骨文裁员消息一出，不仅让很多被裁员工感到无所适从，也让同样处在行业“养尊处优”岗位上的程序员们感到危机。

尽管甲骨文此次裁员给出了“N+6”这样丰厚的补偿方案，但仍然没有获得全部被裁员工的认同。随后，有员工在公司楼下拉起了横幅，表达对部分赔偿的细节问题以及缓冲期太短的抗议。

王海就是拉横幅中的一个。

王海从国内一所985院校本硕毕业后来到甲骨文，一待就是11年。虽说已有超十年的工作经验，但这些年来，王海在甲骨文内部长期开发和维护着同一个项目，对于公司其他情况了解甚少。

而工作之外，无论是朋友圈子还是家人眼中，王海给人的印象都是“有一份体面且高收入的工作，同时有空余时间兼顾家庭”的成功人士典范。

对于拉横幅抗议，王海也犹豫过，毕竟这意味着要将自己面临的窘境和难堪暴露在公众面前。然而，在事情的不断发酵后，他意识到当下局面已经无法改变，只有尽可能为自己争取更多权益。在他背后，房贷、家庭开销，以及刚刚生二胎而增加的压力，任何一项都足以将他压垮。

除了争取更多的赔偿，如何找下一份工作也让王海感到发愁。在他看来，比现在更高薪资的工作机会要求也更高，而自己的技术水平可能并不具备太多竞争力。除此之外，高薪还意味着多劳，“人到中年的身体状况，恐怕是吃不消熬夜加班了。”对于国内多数企业快节奏的工作方式，王海内心充满“抵触”情绪，但他知道，如果追求与现在节奏相似的工作，与之匹配的薪资必然负担不了一家人现有水平的生活。

王海面临的困境，并不是个案。拉勾网在其公众号上撰文表示，甲骨文此次被裁员工中，高学历、但年龄偏大的程序员居多。而甲骨文内部人员也透露，此次被裁员工的平均年龄是37岁，这一年龄在中国互联网行业尤其是程序员界几乎没有任何优势。

与甲骨文深陷舆论风波不同，在上海闵行紫竹科学园上班的微软和英特尔员工依然每天规律地乘坐着准点通勤车来往于公司和市区各主要交通枢纽之间。

在微软工作的李波和在英特尔工作的张涛都是公司的FTE（全职员工），两人所在部门的工作都围绕这两大巨头传统优势业务展开。部门里除了少部分FTE之外，大多为实习生和外包人员。

以李波的工作节奏，大多数时候他都能乘上下午六点钟的班车回家，即使遇上加班，也只到晚上八九点为止。且在日常工作日中，李波和大多数同事一样，可以偶尔申请在家办公。

即便如此，李波仍然羡慕在大楼对面的英特尔员工，毕竟他们的下班时间还要更早一个小时。

“朝八晚五是真的，多数员工每年有十几天年假，公司还会给员工的爱人和孩子购买补充医疗保险；如果因为时差在家办公，每个月还会发放网络补助等。”除这些福利，张涛认为，英特尔更为人性化的是尊重员工个性，鼓励员工学习更多兴趣技能，“毫不夸张地说，我在公司有近一半的时间花在培训课上。”

羡慕之余，李波更多地是为此感到焦虑，因为公司在行业技术上的优势和成熟，多数工程师在工作中用到的技术和组件都比较完整且封闭，“不一定能接触到很核心的东西，”李波坦言，“如果有一天被裁员，我现有的技术水平不一定能比得上应届生。”张涛称，他也做过了“最坏”的打算：“如果离职跳槽的话，我们这几家可以互跳，工作氛围和薪资也都差不多。”

在他们看来，虽然微软和英特尔因业务调整，近年来不时在全球范围内裁员，但两人所在的部门都没有遭遇裁员危机。因此，两人几乎一致性地认为，在他们可预见的剩余的职业生涯中，微软和英特尔并不会裁撤其所在部门，如今的工作和生活，他们似乎能一直过下去。

相比“老一辈”的程序员，李子晴认为自己更有忧患意识。

在2017年毕业后，李子晴应聘进入微软较为边缘的部门，后通过公司内部激励机制，最终凭借突出表现成功换到了理想部门。现在，李子晴在基本工作完成的前提下，还获准参与包括接触美国市场的核心项目，这让她充满了工作热情。

虽然每天都维持在10个小时左右的工作时长，但李子晴依然会因为害怕落后而感到焦虑，“因为周围同事都十分优秀，所以我有时候还会主动加班，为了掌握更多技能，争取缩短差距。”

在英特尔工作的程光也表示，公司内部资源渠道较多，团队之间大都能够顺畅沟通和合作，例如当项目遇到技术难题不能解决时，公司甚至会调用其他部门有经验的人或者其他企业的人员来协助，甚至有时候会为此请高校教授来交流。

“一些部门leader的观念是，怎么把项目做好、找出问题的解决办法是下属的事，他们的事就是帮我们找各种资源，这给了很多人提升空间。”程光说道，公司大楼经常到很晚还有人在敲代码，这其中大多数并不是为了给同事和老板看，也不是因为公司要求，而是出于对自我的要求。

对于李子晴和程光来说，当下最重要的是利用公司提供的足够大的平台和丰富的资源充分提升自己，这样则不必担心有一天会突然“被失业”。

“就算某天所做的业务被裁撤，我也对自己有信心能够再找到相当甚至更好的。”程光在匆忙解决完晚餐后，又一头扎回了电脑前。

王春华有多年猎头经验，经历过数次外企在中国的大规模裁员。她总结道，很多外企程序员离职后，大部分还是流向其他外企，“无论从工作和生活的平衡度，还是从企业文化的认同感来说，这些程序员在外企之间流动，都更容易快速适应，试错成本和风险相对较小。”

然而值得注意的是，在外企纷纷裁撤部分中国业务的趋势下，仅剩不多的“高位”和“好位”，也面临着更激烈的竞争。

王春华表示，这些从外企流出的人员中，还有相当一部分流向国内互联网大厂。

一位微软的HR表示，一些国内互联网和国内外芯片及手机巨头等，都十分喜欢微软出身且技术能力过关的程序员，例如处于高速扩张阶段的今日头条和拼多多。 “我们这里2-5年从业经验的年轻程序员，年薪集中在25万-40万，今日头条和拼多多在挖人的时候一般都会涨薪30%-50%，有时甚至开出翻倍薪资，还附加股票、期权等其他收入。”

拉勾网最近公布的一组数据显示，目前国互联网公司求职难度已高于外企。自从2014年以来，应聘者投简历到国内互联网公司的平均邀约率为0.79%，而外企的平均邀约率达到4.21%，前者不到后者两成。

有业内资深HR透露，目前国内互联网龙头企业在招聘程序员进行初步筛选时已十分苛刻，“首先看专业素质，基础过硬，学习能力强，有前瞻的洞察力；其次是要有良好的沟通协作能力和抗压适应能力；最后，还要对业务有较深刻的理解，最好懂一些管理。”他表示，应聘者在经过初步筛选后，随后还要接受多轮笔试、面试、实操的考核，对于高级管理人员的筛选，则有更高的要求。

“外企中因为有大量外包人员和实习生在一线写代码，部分外企程序员的基本功不一定非常扎实。”某云计算创业公司HR直言，但这部分外企程序员起点较高，往往要求更高的薪资，年龄也更大，公司需承担的人力成本也更高，因此他们与应届毕业生相比并没有太多优势。

根据行业统计，在外企程序员中，应届硕士起薪多数可达20万元一年，在工作三五年后，可涨至30万-40万的年薪。而工作五至八年后，该数字可上升为60万左右。因此当到了管理级别，年薪百万十分常见。

根据上海多位HR的反馈，目前HP、IBM、 Oracle、Autodesk、 Adobe，和Redhat等企业的流出员工竞争力下降尤为明显，这也与这些企业近年来在中国及全球市场上的战略布局和发展速度不无关系，其中Oracle和IBM在中国更是一直以“钱多活少离家近”的“养老院”著称。

如今，在参加了几场线上和线下的专场招聘会后，王海重新对自己做了一次评估，他认为当下最为“靠谱”的还是，重点投递与此前甲骨文类似的外企相关岗位。

（应受访人要求，文中刘楠、王海、李波、张涛、李子晴、程光、王春华均为化名）

程序员笔记——如何编写优雅的Dockerfile

Sun, 28 Apr 2019 15:35:09 CST

导读

Kubernetes要从容器化开始，而容器又需要从Dockerfile开始，本文将介绍如何写出一个优雅的Dockerfile文件。

文章主要内容包括：

Docker容器
Dockerfile
使用多阶构建

感谢公司提供大量机器资源及时间让我们可以实践，感谢在此专题上不断实践的部分项目及人员的支持。

一、Docker容器

1.1 容器的特点

我们都知道容器就是一个标准的软件单元，它有以下特点：

随处运行：容器可以将代码与配置文件和相关依赖库进行打包，从而确保在任何环境下的运行都是一致的。
高资源利用率：容器提供进程级的隔离，因此可以更加精细地设置CPU和内存的使用率，进而更好地利用服务器的计算资源。
快速扩展：每个容器都可作为单独的进程予以运行，并且可以共享底层操作系统的系统资源，这样一来可以加快容器的启动和停止效率。

1.2 Docker容器

目前市面上的主流容器引擎有Docker、Rocket/rkt、OpenVZ/Odin等等，而独霸一方的容器引擎就是使用最多的Docker容器引擎。

Docker容器是与系统其他部分隔离开的一系列进程，运行这些进程所需的所有文件都由另一个镜像提供，从开发到测试再到生产的整个过程中，Linux 容器都具有可移植性和一致性。相对于依赖重复传统测试环境的开发渠道，容器的运行速度要快得多，并且支持在多种主流云平台（PaaS）和本地系统上部署。Docker容器很好地解决了“开发环境能正常跑，一上线就各种崩”的尴尬。

Docker容器的特点：

轻量：容器是进程级的资源隔离，而虚拟机是操作系统级的资源隔离，所以Docker容器相对于虚拟机来说可以节省更多的资源开销，因为Docker容器不再需要GuestOS这一层操作系统了。
快速：容器的启动和创建无需启动GuestOS，可以实现秒级甚至毫秒级的启动。
可移植性：Docker容器技术是将应用及所依赖的库和运行时的环境技术改造包成容器镜像，可以在不同的平台运行。
自动化：容器生态中的容器编排工作（如：Kubernetes）可帮助我们实现容器的自动化管理。

二、Dockerfile

Dockerfile是用来描述文件的构成的文本文档，其中包含了用户可以在使用行调用以组合Image的所有命令，用户还可以使用Docker build实现连续执行多个命令指今行的自动构建。

通过编写Dockerfile生磁镜像，可以为开发、测试团队提供基本一致的环境，从而提升开发、测试团队的效率，不用再为环境不统一而发愁，同时运维也能更加方便地管理我们的镜像。

Dockerfile的语法非常简单，常用的只有11个：

2.1 编写优雅地Dockerfile

编写优雅的Dockerfile主要需要注意以下几点：

Dockerfile文件不宜过长，层级越多最终制作出来的镜像也就越大。
构建出来的镜像不要包含不需要的内容，如日志、安装临时文件等。
尽量使用运行时的基础镜像，不需要将构建时的过程也放到运行时的Dockerfile里。

只要记住以上三点就能写出不错的Dockerfile。

为了方便大家了解，我们用两个Dockerfile实例进行简单的对比：

  FROM ubuntu:16.04
RUN apt-get update
RUN apt-get install -y apt-utils libjpeg-dev \     
python-pip
RUN pip install --upgrade pip
RUN easy_install -U setuptools
RUN apt-get clean

  FROM ubuntu:16.04
RUN apt-get update && apt-get install -y apt-utils \
  libjpeg-dev python-pip \
           && pip install --upgrade pip \
      && easy_install -U setuptools \
    && apt-get clean

我们看第一个Dockerfile，乍一看条理清晰，结构合理，似乎还不错。再看第二个Dockerfile，紧凑，不易阅读，为什么要这么写？

第一个Dockerfile的好处是：当正在执行的过程某一层出错，对其进行修正后再次Build，前面已经执行完成的层不会再次执行。这样能大大减少下次Build的时间，而它的问题就是会因层级变多了而使镜像占用的空间也变大。
第二个Dockerfile把所有的组件全部在一层解决，这样做能一定程度上减少镜像的占用空间，但在制作基础镜像的时候若其中某个组编译出错，修正后再次Build就相当于重头再来了，前面编译好的组件在一个层里，得全部都重新编译一遍，比较消耗时间。

从下表可以看出两个Dockerfile所编译出来的镜像大小：

  $ docker images | grep ubuntu      
REPOSITORY      TAG     IMAGE ID    CREATED     SIZE                                                                                                                                   
ubuntu                   16.04       9361ce633ff1  1 days ago 422MB
ubuntu                   16.04-1   3f5b979df1a9  1 days ago  412MB

呃…. 好像并没有特别的效果，但若Dockerfile非常长的话可以考虑减少层次，因为Dockerfile最高只能有127层。

三、使用多阶构建

Docker在升级到Docker 17.05之后就能支持多阶构建了，为了使镜像更加小巧，我们采用多阶构建的方式来打包镜像。在多阶构建出现之前我们通常使用一个Dockerfile或多个Dockerfile来构建镜像。

3.1单文件构建

在多阶构建出来之前使用单个文件进行构建，单文件就是将所有的构建过程（包括项目的依赖、编译、测试、打包过程）全部包含在一个Dockerfile中之下：

  FROM golang:1.11.4-alpine3.8 AS build-env
ENV GO111MODULE=off
ENV GO15VENDOREXPERIMENT=1
ENV BUILDPATH=github.com/lattecake/hello
RUN mkdir -p /go/src/${BUILDPATH}
COPY ./ /go/src/${BUILDPATH}
RUN cd /go/src/${BUILDPATH} && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go install –v

CMD [/go/bin/hello]

这种的做法会带来一些问题：

Dockerfile文件会特别长，当需要的东西越来越多的时候可维护性指数级将会下降；
镜像层次过多，镜像的体积会逐步增大，部署也会变得越来越慢；
代码存在泄漏风险。

以Golang为例，它运行时不依赖任何环境，只需要有一个编译环境，那这个编译环境在实际运行时是没有任务作用的，编译完成后，那些源码和编译器已经没有任务用处了也就没必要留在镜像里。

上表可以看到，单文件构建最终占用了312MB的空间。

3.2 多文件构建

在多阶构建出来之前有没有好的解决方案呢？有，比如采用多文件构建或在构建服务器上安装编译器，不过在构建服务器上安装编译器这种方法我们就不推荐了，因为在构建服务器上安装编译器会导致构建服务器变得非常臃肿，需要适配各个语言多个版本、依赖，容易出错，维护成本高。所以我们只介绍多文件构建的方式。

多文件构建，其实就是使用多个Dockerfile，然后通过脚本将它们进行组合。假设有三个文件分别是：Dockerfile.run、Dockerfile.build、build.sh。

Dockerfile.run就是运行时程序所必须需要的一些组件的Dockerfile，它包含了最精简的库；
Dockerfile.build只是用来构建，构建完就没用了；
build.sh的功能就是将Dockerfile.run和Dockerfile.build进行组成，把Dockerfile.build构建好的东西拿出来，然后再执行Dockerfile.run，算是一个调度的角色。

Dockerfile.build

  FROM golang:1.11.4-alpine3.8 AS build-env
ENV GO111MODULE=off
ENV GO15VENDOREXPERIMENT=1
ENV BUILDPATH=github.com/lattecake/hello
RUN mkdir -p /go/src/${BUILDPATH}
COPY ./ /go/src/${BUILDPATH}
RUN cd /go/src/${BUILDPATH} && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go install –v

Dockerfile.run

  FROM alpine:latest
RUN apk –no-cache add ca-certificates
WORKDIR /root
ADD hello .
CMD ["./hello"]

Build.sh

  #!/bin/sh
docker build -t –rm hello:build . -f Dockerfile.build
docker create –name extract hello:build
docker cp extract:/go/bin/hello ./hello
docker rm -f extract
docker build –no-cache -t –rm hello:run . -f Dockerfile.run
rm -rf ./hello

执行build.sh完成项目的构建。

从上表可以看到，多文件构建大大减小了镜像的占用空间，但它有三个文件需要管理，维护成本也更高一些。

3.3 多阶构建

最后我们来看看万众期待的多阶构建。

完成多阶段构建我们只需要在Dockerfile中多次使用FORM声明，每次FROM指令可以使用不同的基础镜像，并且每次FROM指令都会开始新的构建，我们可以选择将一个阶段的构建结果复制到另一个阶段，在最终的镜像中只会留下最后一次构建的结果，这样就可以很容易地解决前面提到的问题，并且只需要编写一个Dockerfile文件。这里值得注意的是：需要确保Docker的版本在17.05及以上。下面我们来说说具体操作。

在Dockerfile里可以使用as来为某一阶段取一个别名”build-env”：

  FROM golang:1.11.2-alpine3.8 AS build-env

然后从上一阶段的镜像中复制文件，也可以复制任意镜像中的文件：

  COPY –from=build-env /go/bin/hello /usr/bin/hello

看一个简单的例子：

  FROM golang:1.11.4-alpine3.8 AS build-env
 
ENV GO111MODULE=off
ENV GO15VENDOREXPERIMENT=1
ENV GITPATH=github.com/lattecake/hello
RUN mkdir -p /go/src/${GITPATH}
COPY ./ /go/src/${GITPATH}
RUN cd /go/src/${GITPATH} && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go install -v
 
FROM alpine:latest
ENV apk –no-cache add ca-certificates
COPY --from=build-env /go/bin/hello /root/hello
WORKDIR /root
CMD ["/root/hello"]

执行docker build -t –rm hello3 .后再执行docker images ，然后我们来看镜像的大小：

多阶构建给我们带来很多便利，最大的优势是在保证运行镜像足够小的情况下还减轻了Dockerfile的维护负担，因此我们极力推荐使用多阶构建来将你的代码打包成Docker 镜像。

作者：王聪

内容来源：宜信技术学院

这些知识决定了程序员的上限

Mon, 22 Apr 2019 19:29:34 CST

讲述决定程序员上限的一些知识技能点，包括如何学习、如何阅读源码、计算机科学基础知识体系等。

什么是程序员？

码农、程序猿、程序媛
使用程序实现价值
程序=数据+算法
软件=程序+软件工程
程序员=工程师？

程序员金字塔

程序员知识结构

面试造火箭，工作打蚊子
会什么是你的下限，能够会什么是你的上限
越底层的东西越决定上限

学习欲望

杜绝 1年工作经验重复 N年

如果自己遇到这种问题会怎么解决，与资料中的解决方案相比优劣如何？
别人为什么会想到这种解决方案？
自己是由于经验欠缺还是技能点欠缺才导致没有想到好的解决方案？
解决这类问题的根本思路是什么样的？

学习能力

不是懂得多，而是学得快

知其然更要知其所以然：技术以深度优先
类比现实：对现实世界的模拟
更好地接受信息：建立自己的知识体系；阅读并记笔记，纳入知识体系
深度思考：阅读书籍
动手实践、频繁练习：项目驱动型学习；主动思考
自我总结：完善知识体系；笔记、博客、分享
持续学习：逃离舒适区；学到老，活到老

如何学习新技术

如何阅读源码

阅读该技术的架构文档，了解其总体架构和组成
根据总体架构，将源码文件以模块或者上下层级进行分类。
从未阅读过的模块中选择最独立（依赖性最小）的模块代码读起。
阅读此模块的功能介绍文档。
阅读此模块的源代码： 运行程序，断点调试。
一边阅读一边整理调用关系图。
转到第三步。

参考 官方文档或者经典书籍

计算机思维

冯.诺依曼体系：程序存储，顺序执行。
二进制存储：用比特解决问题
位运算：位运算的高效
逻辑分支：条件判断、循环、迭代、递归

个人规划

长期规划：职业规划；高瞻远瞩
短期规划：具体技能、晋升、学习方面的规划；优先级排序

基础学科

物理：电路原理；量子计算机
数学：工程优化；线性代数；微积分
英语！！：阅读英文文献；计算机术语

计算机组成原理

计算机的硬件组成和运行原理

冯诺依曼体系、 摩尔定律、 阿曼达定律
数据的机器表示：原码、补码、反码、浮点数/定点数
指令系统：复杂指令集、简单指令集
存储器：分类、缓存
CPU: 流水线、伪共享、缓存
IO设备：IO总线、DMA、中断

计算机操作系统

屏蔽计算机硬件的中间层

作业调度: 调度策略、优先级
进程管理：进程和线程、进程间通信
存储管理：内存、虚拟内存、文件系统、页、页缓存
IO管理：IO设备读写操作
Linux操作系统

计算机网络

单个计算机之间的互连

TCP/IP协议栈：四层/七层
TCP连接状态
TCP与UDP的区别
HTTP协议、RESTful规范
网络安全
下一代互联网：IPv6、物联网、5G

编译原理

将代码转换成机器可理解的二进制，有助于实现DSL

词法分析、语法分析
类型检查
运行时环境、中间代码
代码生成、代码优化

数据结构和算法

程序=数据+算法

基本数据结构：数组、链表、栈、队列、哈希表
最大堆、最小堆：TopN问题
树：平衡二叉树、B树、B+树、红黑树
跳跃表: 简单可实现
经典排序算法：快速排序、归并排序、插入排序、冒泡排序
经典查找算法：顺序查找、二分查找
高级算法：贪心、分治、回溯、动态规划
大数据处理：Bitmap、Bloomfilter、Hyperloglog、MapReduce、MPP

设计模式

软件可复用、可扩展、可维护。善用而不滥用。

面向对象SOLID设计原则：单一职责、开闭原则、里氏代换、接口隔离、依赖倒转
常用设计模式：单例模式、工厂模式、代理模式、适配器模式、观察者模式
常用框架中的设计模式：Spring

[程序员] 从高德采集最新的省市区三级坐标和行政区域边界 csv 格式

Tue, 16 Apr 2019 08:36:27 CST

当然还是用 js 在浏览器中运行采集的啦，包含采集源码，可自行采集，采集请求数据部分仅需 2 分钟。

数据下载： https://github.com/xiangyuecn/AreaCity-JsSpider-StatsGov/releases

数据预览：

另 20 天前发了一个帖子 /t/548567 对应的省市区镇数据采集。

另 117 天前发了一个帖子 /t/512328 咨询过城市变更我们数据库里面的老数据应对方案，虽然没什么好的结论，但还是可以参考参考。

为啥不用百度地图，其实最开始用的百度的，采集完才发现百度地图的数据有严重问题，然后才选择的高德。

嘲讽一下百度地图：

大量的这种垃圾数据，这么一看高德简直完美无比。

微软变了！招程序员的流程完全改了

Sat, 05 Jan 2019 19:42:51 CST

【伯乐在线导读】：在微软新 CEO 萨蒂亚·纳德拉的领导下，微软试图改革公司文化，让整个公司朝着同一个方向发展。为此，微软在 2016 年开始研究「替代面试框架（Alternative Interview Framework）」。这是一种在开发部门进行面试的新方式，目的是减少偏见，更好地测试求职者在工作中实际需要的技能。该团队首先在自己身上测试了面试过程，并在过程中不断改进。

本文作者约翰·蒙哥马利（John Montgomery）是微软项目管理合伙人，他也是新面试流程的负责人。本文写于 2018 年 12 月 15 日，原标题：《Rethinking how we interview in Microsoft’s Developer Division | 对微软开发者部门招聘流程的反思》。以下是伯乐在线的译文：

几年前，我有了一系列的顿悟。我刚刚和团队讨论了我们将如何改变项目经理的角色。少关注待办事项，多关注业务；少强调“知道”，多强调“学习和质疑”；更多地关注与客户一对一的接触，而不是聚合数据。我们想把能帮助我们改变这种文化的人带到团队中，但我们仍然在问同样的面试问题，使用同样的面试风格。所以反思了我们是如何面试候选人的，并想出了一些适合我们的方法。

新面试流程我们已经用了一段时间了，我认为有必要分享一下我们所做的，以及学到的东西。

第 1 个顿悟：我们仍然在问一些过时（和无效）的面试题

第一个顿悟是我首次从程序员转为项目经理之后，我们注意到，我们仍然在问过去 10 年或更长的时间里一直在问的面试题。如果我们想寻找能够将不同技能和观点的新人带入团队，那些面试题就没有意义了。（补充：我在微软工作时，我们还在问为什么下水道井盖是圆的，一架波音 747 飞机能装满多少个乒乓球，以及如何反转一个链表。在微软工作的 20 年中，我还没有编写代码来反转链表，或用任何类型的球堆满波音 747。）

不仅如此，有时两个面试官会无意中问同样的基本问题。即使在协调面试题的时候，面试官之间也是共享着相同的面试题目录。有些基于行为的面试题并不可怕，但我们并没有特别有效地运用它们。

第 2 个顿悟：并不是人人都能在快节奏、高压力的环境中超常发挥

第二次顿悟是在一次会议上。点子冒出来的很快，与会者听着对方的话语，试图把自己的想法融入谈话，我们很快就做出了一些重大决定。至少，我确信这将是一件大事。（我当时被一个客户问题分散了注意力，我正与客户经理和工程团队一起解决客户的问题。这是另一个故事。）不管怎么说，这次会议已经达到了高潮，其中一位与会者，我团队中的一名 PM，他非常聪明，也很安静。他说，“我只是在网上搜索有关我们主题的信息，是的，这个想法行不通。”她的态度比这要好。但让我顿悟的是，并不是所有人都能在那些快节奏的头脑风暴会议中出色表现。很多人（包括我）更喜欢坐着喝杯咖啡，看看数据，试着把事情想清楚。更重要的是，在我的职业生涯中，几乎没有任何一次我们做出重大决定的时候，没有不是离开一段时间，然后用新的眼光、新的数据和新的客户研究来处理点子。

但大多数面试都是快节奏的，那些你从未遇到过的问题，你能有多快地解决？

第 3 个顿悟：观察新人工作能力的最佳方式，是和他们一起工作

在我和一些工程团队谈论他们是如何将新人带入他们团队的时候，第三个顿悟冒出来了。开发者部门做了很多开源工作（.NET Core、VS Code、TypeScript 等等。作为面试过程的一部分，我们开发团队已经开始与应聘者一起解决某个问题或特性。这就是候选人在和团队一起合作，解决实际问题的过程。

把点子写下来，然后迭代

既然“写作就是思考”，我就给自己写了一封电子邮件，讨论我们团队面试流程能有什么样的变化。然后我把自己的想法分享给团队成员，我们开始迭代。 Karen Ng、Amanda Silver、Cindy Alvarez、Nathan Halstead、Anthony Cangialosi、Jeff McAffer、Jessica Rich、Travis Lowdermilk 等成员参与了测试、迭代和测试。

当我们准备推出新面试流程时，我们从很小的地方开始，然后继续学习、迭代，然后扩展。现在，这个新流程（我们称之为“另类面试框架”，因为我们中没有人特别擅长命名事物）是我们的标准实践。我们不断地完善和学习，它对我们非常有效。

下面是我们做的一些不同的事情。

1、提前分享面试

首先，我们要提前几天让候选人知道面试日是什么样的，我们要解决什么样的问题。我们给他们时间去做研究和思考。这并不是说每天上班都是件惊喜的事，那么面试为什么要这样呢?

2、用真实的问题

其次，我们采用了团队正在努力解决的一个实际问题，比如：提高满意度、增加留存率、促进服务或特性的使用。事实上，这是我们正在解决的一个真正的问题，这有助于促进合作对话。

3、候选人可以查阅资料

第三，我们让候选人能拿到与正式员工相同的资料。在面试过程中，他们可以自由上网或搜索更多数据。我们经常向候选人提供我们的客户研究、使用数据、设计和模型——几乎我们所有的一切。

4、让面试更有互动性

我们不是简单地向求职者提问题。面试官和求职者要一起解决问题，所以我们就把求职者当同事看待，一起来解决特定的实际问题。

5、遵循单一场景/问题

第五，我们在面试日都遵循一个单一的场景/问题，带领求职者过一遍类似 PM 会经历的过程，从客户或业务问题开始，理解客户待完成的工作要，设计解决方案，将解决方案交到客户手中，最终让客户使用并爱上它。每次面试都侧重于这一流程中的某一不同的阶段。

6、两个面试官

第六，我们为面试官配对。与一对一的面试不同，我们每次面试都从团队中挑选两个人。我们的最初动机是培养更多的面试官，但有两个面试官在一起还有其他好处。与多个合作者的谈话，不仅更有活力，而且让我们有机会从多个角度观察同一场面试谈话。并不是每个人对同一场面试谈话都有同样的看法，所以，它给了我们一种方法来检查在相同谈话中的无意识偏见。

7、把反馈留到最后

面试官之间的反馈，我们把保留到面试日结束之时。我们希望每位面试官只根据他们谈话的优点来判断候选人，而不是根据他们之前面试官的意见。我们告诉面试官，不要向别人暗示他们是否倾向于推荐我们雇佣某人。他们把候选人交给下一轮面试官，并总结我们在上一环节中学到的东西。在面试日结束的时候，每个面试官同时提出他们的建议，并解释相应理由。

8、总结面试流程的优缺点

第八，在每次面试循环的最后，我们不仅要讨论我们在面试中所学到的东西，还要讨论在面试过程中哪些有用，哪些没用。我们再把这些反馈重新应用到面试流程中，流程会变得更好。

关于新的面试流程，我或许忘了一些，但上述 8 个方面是最重要的。

我们学到了什么?

嗯，我们担心候选人会紧张。面试日有两个面试官和候选人在一起，有真实的问题，还有真实的数据。几乎每个候选人都主动反馈说，新面试流程是独一无二的，真正帮助他们了解我们的业务和团队。即使是那些没有收到录用通知的求职者，也喜欢新的面试流程，明白我们为什么没有录用他们。

不断优化面试流程

我们发现还是有不少要改进的地方。例如，我们 PM 团队是非常有技术性的。许多 PM 将代码 check in 生产产品。这对我们来说是有意义的：我们面试流程的「客户」是开发者，因此拥有来自于创建软件的那种客户理解，是很有帮助的。但在这个过程中，我们并没有很好地深入了解应聘者的技术技能。因此，我们增加了一个面试环节，以进行更技术性的互动。

后勤

我们了解到，相对标准面试流程，新流程的一些相应准备工作真心不容易。举个例子，由于求职者正在处理同样的问题，并在白板上写下他们以后需要的东西，我们需要为求职者保留一个专门的空间（会议室或 Focus Room），面试官会去找求职者。

（补注：Focus Room 是一个消除压力的环境，可以帮助你在缓解压力的同时传递信息。）

面试过程的成本不菲

我们了解到面试是“昂贵的”。“每次两个面试官，我们的时间和人力投入翻了一番，大大增加了日程安排的复杂性。”然而，在最初对费用有些抱怨之后，团队中的每个人都开始看到了好处，就像团队中有更多的人见到了我们潜在的新员工。所以，我们愿意付出这些代价。

最终，招聘流程的目标是把优秀的人员带入团队或公司——确保他们是合适的，会成功，并为他们创造良好的经验，他们才会想要加入。我们和其他几家西雅图的大型科技公司都向一位求职者提供了竞争性的工作机会，她特别选择了我们的团队，因为她非常喜欢这个过程。她碰巧成为了我们在早期实验阶段的候选人之一，她还在这里上班，做的很好。其他很多候选人也类似。所以我说，我们的新面试流程表现的很好。我们仍在学习，但到目前为止，新面试流程的成果已超过我们的预期。

微软变了！招程序员的流程完全改了，首发于文章 - 伯乐在线。

为什么美国程序员工作比中国程序员工作轻松、加班少？

Sat, 22 Dec 2018 11:13:41 CST

美国程序员工作比中国程序员工作轻松、加班少总体来说是事实，但都归结到美国程序员效率更高，制度更好之类就过于片面了。我觉得主要原因在于别的一些地方，例如加班的边际效用，程序员的生活习惯。

背景：我在 baidu（北京）和 amazon（湾区）都干过，微软研究院（北京）和 google 研究院（湾区）也实习过，因为目前做云计算和开源，所以也接触过很多公司。整体来看，

不觉得美国程序员比国内程序员水平高多少，特别是在年轻人身上。2000 年后计算机专业红火，学生生源好，这些人是当前程序员的主干力量。而且中国教育在工程学科上更加扎实，适合培养程序员。
美国有非常厉害的领导者，例如几家大公司创始人都很厉害。但加班文化更多是每个项目的实管人控制。我见过好的，也见过差的。虽然没有具体统计过比例，但没觉得中美差异明显。
美国这边开会确实要多一些，但这个也是美国教育重视沟通相关（3，4 岁的小孩就开始练习演讲了）。开会对于大组织有用，这样可以几百人在同一个思想层面往前冲，但用这个来衡量百来人的小公司就不见得适当了。
美国公司创新度更高，一是社会认可，二是不创新难有机会生存，三是国内只盯着创新的公司看。但创新公司加班很普遍，例如 Tesla 老大都睡在厂房。

所以我觉得问题在于一些更本质的东西。这里是我的几点观察：

第一是边际效用。美国社会成熟度比较高，在湾区生活的同学也许过去 10 年都感觉不到特别大的变化，而中国则翻天幅度，特别是互联网领域。例如手机支付，美国普及很难，因为信用卡已经很普及了，手机支付带来的好处不显得很大。但中国的基础设施没跟上，所以手机支付在便利性上提升特别大，同样的技术，大家会不惜余力的去推广。

经济学上这个叫做边际效用。同样的技术，中国的边际效用比较高，所以大家可以全力推广。美国因为起点高，所以更加谨慎一些。

这个影响到了加班文化。通过加班可以完成更多工作。如果项目经理觉得这些工作带来丰厚回报，他们肯定会压着组员做。在中国很可能是这样，例如做出这个产品马上会有人用，升职加薪跟着就来。然而在美国，即使今天做出来，用户也是慢慢的过来，完全不需要急着那么几天。

第二是生活习惯。美国程序员年龄普遍偏大，因为计算机行业在 2000 年在美国就很红火（参考互联网泡沫），培养的大量的程序员，这些人现在很多都有小孩。在美国小孩都是自己带，双方父母不怎么帮忙。请人又特别贵，例如湾区工作日请人带娃一个月起码是 2 千美金起。而且学校课程松，所以放学后都要靠父母照顾。此外，很多人住的房子都带院子，请人打理费用贵，很多时候大家亲自动手。例如 Robin 在创立百度前曾醉心于在湾区种菜。

于是在加班边际效用不高的情况下，大家纷纷早点下班回家做家务。并冠冕堂皇的叫 work-life balance。

我认识好几个未婚朋友，他们觉得每天那么早下班实在是太寂寞，毅然回国去了创业公司，并对 996 大家赞赏。记得 Andrew Ng 也表达过类似的观点。

但反过来说，早 9 晚 5 真的好？计算机技术日新月异，而且随着经历增长，需要提升各项领导能力。这些都需要足够多的时间去学习。我认识的厉害的人无一不是在下班后努力挤出时间工作，丝毫不比 996 工作时间少。与其现在羡慕别人轻松，不如埋头努力工作十年再来看。