首先，Backpressure 并不是响应式编程（Reactive Programming，或者有的人喜欢按字直译为「反应式编程」）独有的；其次，Backpressure 并不是一种「机制」，也不是一种「策略」。Backpressure 其实是一种现象：在数据流从上游生产者向下游消费者传输的过程中，上游生产速度大于下游消费速度，导致下游的 Buffer 溢出，这种现象就叫做 Backpressure 出现。
编程中的 Backpressure 这个概念源自工程概念中的 Backpressure：在管道运输中，气流或液流由于管道突然变细、急弯等原因导致由某处出现了下游向上游的逆向压力，这种情况称作「back pressure」。这是一个很直观的词：向后的、往回的压力——back pressure。可是，国内的热力工程界对这个词的正式翻译是「背压」，把「back」翻译成了「背」，着实有点让人无力吐槽。
图数据结构，能够很自然地表征现实世界。比如用户、门店、骑手这些实体可以用图中的点来表示，用户到门店的消费行为、骑手给用户的送餐行为可以用图中的边来表示。使用图的方式对场景建模，便于描述复杂关系。在美团，也有比较多的图数据存储及多跳查询需求，概括起来主要包括以下 4 个方面：
总体来说，美团需要一种组件来管理千亿级别的图数据，解决图数据存储以及多跳查询问题。海量图数据的高效存储和查询是图数据库研究的核心课题，如何在大规模分布式场景中进行工程落地是我们面临的痛点问题。传统的关系型数据库、NoSQL 数据库可以用来存储图数据，但是不能很好处理图上多跳查询这一高频的操作。
稳定、高效、可靠的基础设施是互联网企业应对业务高峰流量的底层基石。作为美团统一的基础技术平台，基础技术部一直致力于通过业内前沿技术的落地，保障公司内部所有业务在线生产系统所依赖的基础技术平台能稳定、安全、低成本、可持续地运行与发展。
弹性伸缩系统是基于Docker开发的自动弹性伸缩平台，在美团经历了多年的发展。
早在2016年，美团就在线上环境中尝试使用容器环境，推出了基于OpenStack的容器集群平台Hulk 1.0。随着容器的落地，弹性伸缩1.0版本应运而生，它解决了扩容实例慢、扩容上线慢、资源回收慢、计算资源冗余等问题。
在多租户环境中，多个客户（租户）共享相同的应用程序，它们在相同的操作系统上，相同的硬件上以相同的数据存储机制运行。客户之间的区别是在应用程序设计期间实现的。客户不会共享或看到彼此的数据。与每个用户都有自己专用环境的专用系统相比，这样做的主要动机是降低每位用户的成本。
字面意思是比较和交换，先看看下面场景（A 和 B 线程同时执行下面的代码）：
int i = 10; //代码 1
i = 20; //代码 2
场景 1：A 线程执行代码 1 和代码 2，然后 B 线程执行代码 1 和代码 2，CAS 成功。
场景 2：A 线程执行代码 1，此时 B 线程执行代码 1 和代码 2，A 线程执行代码 2，CAS 不成功，为什么呢？
Kafka出色的I/O优化以及多处异步化设计，相比其他消息队列系统具有更高的吞吐，同时能够保证不错的延迟，十分适合应用在整个大数据生态中。
目前在美团数据平台中，Kafka承担着数据缓冲和分发的角色。如下图所示，业务日志、接入层Nginx日志或线上DB数据通过数据采集层发送到Kafka，后续数据被用户的实时作业消费、计算，或经过数仓的ODS层用作数仓生产，还有一部分则会进入公司统一日志中心，帮助工程师排查线上问题。
很多技术同学都知道，移动端往往比较侧重业务开发，这会导致人员规模不断扩大，项目复杂度也会持续增长。而为了满足业务的快速上线，很难去落实统一的设计规范，在开发过程中由于UI缺乏标准导致的问题不断凸显，具体体现在以下4个层面：
麻省理工学院信息系统研究中心首席研究科学家Jeanne Ross在企业架构研究方面具有26年的丰富经验，她为具有抱负的企业架构师提供了建议，并讨论了最新趋势。
随着业务战略和企业体系结构的融合，IT专业人员仍然扮演着至关重要的角色，有助于洞察技术上的可能性并展望下一项重大创新。
与您在该领域起步时所看到的相比，如今的从业人员企业体系结构有何不同?
Ross：我们已经看到了技术如何帮助企业实现目标，而我们所要做的就是受到技术启发的世界。必须不断地意识到下一个可能发生的事情，并问自己：“我们应该以某种方式做出回应吗?我们可以利用这种新事物为客户做些什么吗?”企业架构师拥有巨大的机会，可以帮助他们准确地了解新现实，从而为企业带来价值。
2020 年，新冠肺炎疫情催化数字化生活方式渐成常态。在企业积极进行数字化转型、全面提升效率的今天，几乎无人否认背负“降本增效”使命诞生的 Serverless 即将成为云时代新的计算范式。
Serverless 将开发者从繁重的手动资源管理和性能优化中解放出来，正在引发云计算生产力的新变革。
然而，Serverless 的落地问题却往往很棘手，例如传统项目如何迁移到 Serverless，同时保障迁移过程业务连续性，在 Serverless 架构下如何提供完善的开发工具、有效的调试诊断工具，如何利用 Serverless 做更好的节约成本等，每一个都是难题。
尤其涉及到在主流场景大规模的落地 Serverless ，更是并非易事。正因为这样，业界对于 Serverless 核心场景规模化落地最佳实践的呼唤更加迫切。
IT的现代化是建立一个敏捷的、响应迅速的企业的关键组成部分。IT领导者们就如何将传统技术转化为数字资产提供了建议。
今年的非同寻常的事件强调了对现代技术环境的需求，即一个足够敏捷、反应迅速的技术环境，能够满足快速变化的业务动态–无论是新兴的收入机会还是在家办公的任务。
这就意味着要有一个可以使遗留应用程序现代化的战略计划。
“摆脱遗留问题是一个长期存在的问题，但实现现代化是现在的一个比以往任何时候都要更加重要的问题，”管理咨询公司Swingtide的总裁兼首席执行官、前首席信息官Diane Carco表示。
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语言的经验丰富的开发人员。但将它们一起应用将允许您构建真正满足业务需求的系统。
