Gartner预测，全球最终用户的公共云支出明年将增长18%，达到3049亿美元，高于今年的2575亿美元
在冠状病毒大流行期间支撑世界经济，全球供应链和远程员工队伍的云计算将继续成为寻求在2021年提高可扩展性，业务连续性和成本效率的组织的基本目标。
总部位于加利福尼亚州圣克拉拉的IT服务提供商InterVision云服务领域首席技术官Dustin Milberg表示：“ COVID-19的影响将持续到2021年，因为企业将寻求为提高敏捷性奠定基础。和AWS Premier咨询合作伙伴。“鉴于云具有改善的可访问性，可扩展性和灵活性的优势，它将成为该目标的重点。”
通常一个初创型项目，都是从单体架构开始的。
优点就是快，易于开发、测试、部署，一个WAR包发上生产就完事了。
缺点也很明显，因为所有模块都在一个程序包里，导致编译慢、启动慢、代码冲突，每次合并代码的时候都是恶梦，发布成功率？完全靠运气。
近几年技术发展十分迅猛，让部分同学养成了一种学习知识停留在表面，只会调用一些指令的习惯。我们时常有一种“我会用这个技术、这个框架”的错觉，等到真正遇到问题，才发现事情没有那么简单。
而Git也是一个大部分人都知道如何去使用它，知道有哪些命令，却只有少部分人知道具体原理的东西。了解一些底层的东西，可以更好的帮你理清思路，知道你真正在操作什么，不会迷失在Git大量的指令和参数上面。
这里会用一个简单的例子让大家直观感受一下git是怎么储存信息的。
老程序员一枚。
一直想分析一下996诞生的原因，就在这里分享一下吧。
软件之于中国一直是一种十分尴尬的存在，见过太多愿意花几百万买计算机但是不舍得几万块软件的企业，单位，个人。软件行业自从在中国出现就一直没有获得相应的地位，资金不足，地位不足，尊重不足成了长期的核心问题。
可能有人会说八十年代初期，还是有些做软件的活的挺滋润，代表就是现在还存在的金山。那会儿软件的价格一套也能卖个几百块，在那个平均工资几十块的年代也不算少了，但是海量的盗版，软件巨头和国家的放任让这种成功成了昙花一现，金山苦苦支撑，江民几乎白送，国内软件公司几乎都陷入了无法生存的窘境。
目前的处理器的处理能力要远远的胜于主内存（DRAM）访问的效率，往往主内存执行一次读写操作所需的时间足够处理器执行上百次指令。所以为了填补处理器与主内存之间的差距，设计者们在主内存和处理器直接引入了高速缓存（Cache）。如图：
架构是针对某种特定目标系统的具有体系性的、普遍性的问题而提供的通用的解决方案，架构往往是对复杂形态的一种共性的体系抽象。
业务架构体系是针对企事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案，更确切的说，是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，比如业务架构体系认为一个信息系统必须由组织机构、业务流程、业务信息、业务功能、和业务语义等层次构成。
复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。
ZGC（The Z Garbage Collector）是JDK 11中推出的一款低延迟垃圾回收器，它的设计目标包括：
从设计目标来看，我们知道ZGC适用于大内存低延迟服务的内存管理和回收。本文主要介绍ZGC在低延时场景中的应用和卓越表现，文章内容主要分为四部分：
HarmonyOS是一款“面向未来”、面向全场景（移动办公、运动健康、社交通信、媒体娱乐等）的分布式操作系统。在传统的单设备系统能力的基础上，HarmonyOS提出了基于同一套系统能力、适配多种终端形态的分布式理念，能够支持多种终端设备。
Nginx是一款轻量级的 Web服务器 / 反向代理服务器 / 电子邮件（IMAP/POP3）代理服务器，主要的优点是：
如果你问自己是否Apache Kafka比RabbitMQ更好或RabbitMQ是否比Apache Kafka更可靠，我想在这里阻止你。本文将从更广泛的角度讨论这两种情况。它关注的是这两个系统提供的功能，并将指导您做出正确的决定，决定何时使用哪个系统。
web上的一些文章让Apache Kafka在RabbitMQ面前大出风头，而另一些文章则恰恰相反。我们中的很多人可能会因为听了大肆宣传，跟着人群跑而认罪。我觉得重要的是要知道是使用RabbitMQ还是Kafka取决于您项目的需求，只有当您在合适的场景中使用了正确的设置，才能进行真正的比较。
今天的企业应用程序无疑是复杂的，并依赖一些专门技术来完成它们的工作。作为开发人员，我们倾向于关注这些技术细节是可以理解的。但事实是，一个不能解决业务需求的系统对任何人都没有用，无论它看起来多么漂亮或者如何很好地构建其基础设施。
领域驱动设计（DDD）的理念 – 首先由Eric Evans在他的同名书[1]中描述 – 是关于将我们的注意力放在应用程序的核心，关注业务领域固有的复杂性本身。我们还将核心域（业务独有）与支持子域（通常是通用的，如金钱或时间）区分开来，并将更多的设计工作放在核心上。
域驱动设计包含一组用于从域模型构建企业应用程序的模式。在您的软件生涯中，您可能已经遇到过许多这样的想法，特别是如果您是OO语言的经验丰富的开发人员。但将它们一起应用将允许您构建真正满足业务需求的系统。
没有必要过度关注本文中二叉树的增删改导致的结构改变，规则操作什么的了解一下就好，看不下去就跳过，本文过多的XX树操作图片纯粹是为了作为规则记录，该文章主要目的是增强下个人对各种常用XX树的设计及缘由的了解，也从中了解到常用的实现案例使用XX树实现的原因。
数据在计算机中的存储结构主要为顺序存储结构、链式存储结构、索引存储结构、散列存储结构，其中链式存储结构最常见的示例是链表与树，链式存储结构主要有以下特点：
度：当前节点下的子节点个数
Spark 是 UC Berkeley AMP Lab 开源的通用分布式并行计算框架，目前已成为 Apache 软件基金会的顶级开源项目。Spark 支持多种编程语言，包括 Java、Python、R 和 Scala，同时 Spark 也支持 Hadoop 的底层存储系统 HDFS，但 Spark 不依赖 Hadoop。
Spark 基于 Hadoop MapReduce 算法实现的分布式计算，拥有 Hadoop MapReduce 所具有的优点，并且具有更高的运算速度。Spark 能够比 Hadoop 运算更快，主要原因是：Hadoop 在一次 MapReduce 运算之后，会将数据的运算结果从内存写入到磁盘中，第二次 MapReduce 运算时在从磁盘中读取数据，两次对磁盘的操作，增加了多余的 IO 消耗；而 Spark 则是将数据一直缓存在内存中，运算时直接从内存读取数据，只有在必要时，才将部分数据写入到磁盘中。除此之外，Spark 使用最先进的 DAG（Directed Acyclic Graph,有向无环图）调度程序、查询优化器和物理执行引擎，在处理批量处理以及处理流数据时具有较高的性能。按照Spark 官网的说法，Spark 相对于 Hadoop 而言，Spark 能够达到 100 倍以上的运行负载。
如果你不了解讲内存屏障为什么要讲CPU缓存，接着往后看。
学过《计算机组成原理》的同学应该都听过一个词：时钟周期。什么是时钟周期呢？通俗点来讲就是CPU完成一个基本动作需要的时间周期。对硬件有点认识的同学都知道看CPU好不好一定要看的一个参数：多少多少GHZ。这个GHZ跟时钟周期之间是存在一定的换算关系的，感兴趣的同学可以去自行研究。说明一下：不了解这层换算关系不影响你看后面的内容，只要你对时钟周期有一个基本认知就可以了。
KMP 算法是 D.E.Knuth、J,H,Morris 和 V.R.Pratt 三位神人共同提出的，称之为 Knuth-Morria-Pratt 算法，简称 KMP 算法。该算法相对于 Brute-Force（暴力）算法有比较大的改进，主要是消除了主串指针的回溯，从而使算法效率有了某种程度的提高。
上面说道 KMP 算法主要是通过消除主串指针的回溯来提高匹配的效率的，那么，它是则呢样来消除回溯的呢？就是因为它提取并运用了加速匹配的信息！
在Kubernetes中，服务和Pod的IP地址仅可以在集群网络内部使用，对于集群外的应用是不可见的。为了使外部的应用能够访问集群内的服务，在Kubernetes中目前提供了以下几种方案：
* NodePort
* LoadBalancer
* Ingress简单来说，就是通过service这种资源对象，为后端pod提供一个统一的访问接口，然后将service的统一访问接口映射到群集节点上，最终实现client通过映射到群集节点上的端口访问到后端pod提供的服务。
听到队列相信大家对其并不陌生，在我们现实生活中队列随处可见，去超市结账，你会看见大家都会一排排的站得好好的，等待结账，为什么要站得一排排的，你想象一下大家都没有素质，一窝蜂的上去结账，不仅让这个超市崩溃，还会容易造成各种踩踏事件，当然这些事其实在我们现实中也是会经常发生。
当然在计算机世界中，队列是属于一种数据结构，队列采用的FIFO(first in firstout)，新元素（等待进入队列的元素）总是被插入到尾部，而读取的时候总是从头部开始读取。在计算中队列一般用来做排队(如线程池的等待排队，锁的等待排队)，用来做解耦（生产者消费者模式），异步等等。
在微服务架构体系里面，我们一般会使用到微服务网关或叫API网关。大家都比较清楚，在微服务架构体系下本身是去中心化的架构，通过服务注册中心来实现服务注册发现和消费调用，那么为何又需要使用API网关？
在传统的ESB总线进行服务集成的时候我们就经常谈到一个概念就是位置透明，即需要屏蔽底层业务模块提供API接口服务地址信息，并实现多个微服务API接口的统一出口。即类似设计模式里面经常谈到的门面模式。
首先看下DevOps的定义：
DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发和运营工作必须紧密合作。
在微服务拆分的架构中，各服务拥有自己的数据库，所以常常会遇到服务之间数据通信的问题。比如，B服务数据库的数据来源于A服务的数据库；A服务的数据有变更操作时，需要同步到B服务中。
第一种解决方案:
在代码逻辑中，有相关A服务数据写操作时，以调用接口的方式，调用B服务接口，B服务再将数据写到新的数据库中。这种方式看似简单，但其实“坑”很多。在A服务代码逻辑中会增加大量这种调用接口同步的代码，增加了项目代码的复杂度，以后会越来越难维护。并且，接口调用的方式并不是一个稳定的方式，没有重试机制，没有同步位置记录，接口调用失败了怎么处理，突然的大量接口调用会产生的问题等，这些都要考虑并且在业务中处理。这里会有不少工作量。想到这里，就将这个方案排除了。
Spring Boot 2.3.0.RELEASE 正式发布了几天了，其中有个新的特性：可以将Spring Boot应用代码直接打包为Docker镜像。这是什么科技？我赶紧去官网查了一番才知道用的是基于云原生的Buildpacks技术，这是一个直接将代码转换为容器镜像的技术，它意味着你不用在写Dockerfile文件了。
但是 Spring Boot 2.3.0.RELEASE 的镜像构建插件好像有BUG，等后续修复吧。但是本文的相关实践并不采用官方的插件。
Kubernetes已经成为美团云基础设施的管理引擎，它带来的不仅仅是高效的资源管理，同时也大幅降低了成本，而且为美团云原生架构的推进打下了坚实的基础，支持了Serverless、云原生分布式数据库等一些平台完成容器化和云原生化的建设。
本文根据美团基础架构部王国梁在KubeCon 2020云原生开源峰会Cloud Native + Open Source Virtual Summit China 2020上的演讲内容整理而成。
Kubernetes是让容器应用进入大规模工业生产环境的开源系统，也是集群调度领域的事实标准，目前已被业界广泛接受并得到了大规模的应用。