在自然语言处理中，我们经常思考，怎么样才能做好自然语言的理解工作。对我们人类来说，理解某一个自然语言的文本信息，通常都是通过当前的信息，关联自己大脑中存储的关联信息，最终理解信息。例如“他不喜欢吃苹果，但是喜欢吃冰淇淋”，人在理解的时候关联出大脑中的认知信息：苹果，甜的，口感有点脆；冰淇淋，比苹果甜，口感软糯、冰凉，夏天能解暑；小孩更喜欢吃甜食和冰淇淋。所以结合这样的知识，会推理出更喜欢冰淇淋的若干原因。但是现在很多自然语言理解的工作还是聚焦在信息的层面，现在的理解工作类似于一个贝叶斯概率，从已知的训练文本中寻找符合条件的最大化文本信息。
在自然语言处理中做到像人一样去理解文本是自然语言处理的终极目标，所以现在越来越多的研究上，引入了一些额外的知识，帮助机器做好自然语言文本的理解工作。单纯的文本信息只是外部客观事实的表述，知识则是在文本信息基础之上对外部客观事实的归纳和总结，所以在自然语言处理中加入辅助的知识信息，让自然语言理解的更好。
作为重要的业务支柱，我们在选择使用Web开发技术时，往往需要考虑待选技术在各个方面的优缺点。目前，无论是创业公司、还是独立软件提供商(ISV)，普遍都会从AngularJS、React JS、以及Vue.js三个常用技术中进行挑选，毕竟它们都有着优秀的社区支持。为了进一步让您全面了解这三者之间的区别与优缺点，下面我将详细为您介绍与比较AngularJS、React JS和Vue.js。
根据如下图给出的谷歌(Google)趋势分析结果，Vue.js的市场占有份额最高，React JS次之，AngularJS最少。当然，这只能说明三者的普及与使用程度，而并不能直接体现到底哪一种技术绝对优秀。下面让我们进一步来讨论他们在技术应用上的不同特点
Java Agent 算是JVM的一个插件，以一个Jar包的形式存在。可以做到在运行时期，修改你的字节码文件，从而达到增强、修改等效果，通过 JVM 提供的 Instrumentation API来实现。
一个Java Agent，由以下几个组件构成：
废话不多说，下面正式开始编写这个Agent。
前2篇介绍了 agent 如何去修改我们的业务代码，以及如何去收集、发送 trace 数据，但是agent的作用不仅如此，那么他还对我们的代码做了一些什么事情，会对我们的程序造成什么样的性能影响，本文将为你揭晓。
方法 SkyWalkingAgent#premain 之前讲解过这是 agent 的入口方法，这个方法的 前半部分都是在 加载配置文件、加载插件以及拦截了类加载器以便后面去修改字节码，在此之外agent还有最后一个步骤，就是去加载所有BootService接口的实现类。
阅读更多
本文源码解析使用的版本是 skywalking 7.0 , 不同版本实现上可能由一定差异，但是思想上大致相同
上篇文章介绍了skywalking-agent的整体架构以及插件的加载原理。
但是仅仅知道了他如何去加载插件，那至于在他使用agent去修改业务代码后如何去收集trace数据 那么请继续往下看
在看源码之前，我们先来了解一下 在skywalking中trace数据 是以什么样的数据结构去保存的，这里为了更清晰展示，这里选择从前端查看trace数据的结构
本文涉及到的源码取自版本 : apache-skywalking-apm-7.0.0 ,不同版本实现差异可能会有一些区别,但是大体框架上没有变化的 , 一些地方为了方便理解,我拆分了 lamda 表达式,或者把一些写在一起的代码给做了拆分,但是整体逻辑是不变的
skywalking 是一个 分布式追踪系统 , 他可以帮助我们看到一个请求经过了多少个微服务,中途调用了多少数据库,redis,mq 等中间件, 要实现这样的功能,其实很简单只要在设计系统的时候, 每经过一次请求,每调用一次中间件,都把对应的日志给存起来, 然后提供一个 ui 服务,也同样能实现对应的功能. 但是如果这样做的话, 对代码就有很强的侵入性 , 每一个业务系统都需要修改,在业务代码里去加上对应的日志,对于喜欢偷懒的程序员来说,这是非常不舒服的.
做开发的人都知道自动化测试，自动化测试不需要人为去触发一个个行为，系统自动运行测试用例。价值不言而喻，但是如果自动化测试用例的缺失部分导致系统没完整测试回归可能会给系统带来风险。这里就是流量回放的价值：通过记录线上流量，在开发或者测试环境回放，来发现系统是否能够正常运行，降低代码变动整体系统带来的风险。
通过AOP请求和响应的拦截，并且进行请求和响应的记录，在开发环境通过解析结果进行回放。
面向切面编程，spring的AOP就是一种实现。当然还可以很多其他实现，例如基于jvm的AOP，可以通过在通过装饰jvm中的class实现；例如其他语言也有对应的实现
首先，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）。如图：