作为一个非专业c/c++开发人员，相信很多人跟我一样，常常会在跟c/c++打交道时碰到困难。然而，我们所使用的很多底层的库或软件，却有大量是用c/c++编写而成。所以，了解一些基本的c/c++知识对于非专业c/c++开发人员将非常有帮助。
在下面这些典型的场景中，我们可能会需要用到这些知识：
c/c++项目c/c++程序里面进行少量的c/c++开发，并与c/c++代码交互本文尝试总结一下基本的c/c++知识，包括常见的平台、静态库/动态库的原理、基础编译指令等。并将结合一些实例来加深理解。
在前面的文章中提到我们在一个高性能场景中尝试了rust，那么它的效果如何呢？
在这次rust的尝试中，我们实现了一个通用的特征数据处理框架，并实现了几个常用的算子。这个数据处理框架目标是实现 Spark ML pipeline 的在线计算，为机器学习模型的在线推理场景提供特征处理。
我们选用了两个rust的grpc框架对外提供服务。它们分别是grpc和tonic，前者是基于线程池的实现，后者是基于rust异步模式async/await的实现。实验过程发现两者性能相差不大，tonic稍好，快2ms左右（不到5%），这可能是由于其数据结构设计更为精简带来的。
为了更有参考性，我们直接进行端到端的测试（用grpc客户端发起请求，在客户端采集数据），并与scala版本的实现进行性能对比。下面的结果中，服务端应用均部署在同一台64核心+32GB内存的服务器上，客户端也在此服务器上发起请求。由于数据处理的逻辑一致，客户端使用同一个java版本的实现。
在最近的一个客户项目上，为了做性能优化，我们花了大量的时间，然而最终结果还是不够理想。我们的场景是实现特征处理过程和机器学习模型线上推理服务。由于用户量巨大，我们需要做到2万的TPS，每个请求需要在30ms内返回，且每个请求中包括对1000个项目的处理过程。
我们所使用的技术栈是spring和grpc。在经过极致的代码优化及内存调优之后，运行在一台32GB内存64核CPU的服务器上，我们发现90%的请求可以在25ms完成。但是如果观察99%的分位线时，响应时间就下降到了70ms，有时候还可能超过100ms。
为什么会出现上面这么明显的波动呢？问题出在java的gc上。其实对于gc，我们已经非常仔细的做过调优了，整个过程没有full gc的发生。然而，在持续的压力测试下，java的young gc却在频繁的工作。由于处理的数据量过大，新生代的gc几乎每秒都会触发一次，每次释放5GB内存，耗时30ms左后。
作为我们使用最广泛的CI/CD工具Jenkins，它对于Pipeline as Code的支持却并不能算友好。在多个项目中使用之后，我发现它存在的主要问题有：
Groovy语言相对而言还是比较小众的。其设计为一种动态类型的语言，这给编译器、IDE的类型推断带来了困难，从而导致较弱的自动代码提示。除此之外，由于Groovy可以在没有歧义的情况下省略括号和行尾分号，并且如果最后一个参数是一个闭包则可以将其写在函数调用之后，这就导致了相对比较怪异的语法出现。比如，刚接触Groovy的人可能不太能一下子理解下面这段代码的工作原理：
1 | a(1) { |
昨天和项目组的几个小伙伴去爬山。这次爬山坐标深圳梧桐山。从西北门进山，我们沿着蜿蜒的公路一路而上，历时三小时登顶。下山时不想原路返回，故意选了另一条路。从山上往下看，这条路陡峭得很。不过，对于几个血气方刚的男性，这条路正好。因为大家都觉得上山太简单不过瘾，想挑战一下高难度。于是我们一致同意换路而行。我们走的这条路就是凌云道。
说起凌云道这条路，真是名副其实。它不仅几乎呈垂直高度下降，而且台阶较窄仅有半脚宽。路两边树丛虽然茂盛，但是都不高大，山下的情形总是能进入眼帘。我一向有点恐高，在这垂直高度近1千米地方往下看，还真是心里有点慌。刚开始下山，小伙伴们见此山势，纷纷停下脚步拍照。得几张无P图片如下，大家可以感受一下：
有一个技术人员都知道的很老的段子。如果我们想将一个技术论坛搞火起来，那么我们只需要发一篇帖子“php是世界上最好的语言”。虽然是很老的段子，但是就算现在我也常常能听到有人谈论它。很有意思的一个段子。
不仅仅是在论坛中，在我们日常的团队合作中，其实也常常有这样的事情。回忆一下我的 Code Review 活动，是不是常常有某一行代码引起了大家的广泛讨论，把整个会议给“搞火”了？大家可能就一个问题讨论很久，争执不下。
对于这样的讨论，如果大家能心平气和，互相理解，可能能较快的达成一致。但是事实上常常会出现这样的情况，双方争论很久争执不下，后来可能有人说，“这你都不知道啊”，或者“这我理解不了，你这里明显有问题”，或者“你说的都好，我用我的方式”，或者“你这里就明显是在#define true=false”等等。在这样的讨论中，我们比较容易情绪化（可能没有情绪化这么严重，但是这里姑且先用这个词），最后本来应该心平气和的讨论演变成了针对某个个人的互怼，或者直接拒绝交流。一旦情况变成这样，那么不仅讨论效率会大大下降，而且常常在相互心中产生芥蒂，影响后面的高效合作。
我时常在项目中听到一些经验稍欠缺的开发人员在Code Review时这么讲：
这里为了方便测试我抽取了一个纯函数，这个函数包含了主要的业务逻辑，测试覆盖率也比较高，我们可以认为这一部分质量不错。
使用这个函数的地方由于集成度高不好测试，我们就不做自动化测试了。
他的代码可能写成下面这样：
1 | // some_file.ts |
随着微服务和DDD的兴起，领域这个词逐渐成为了一个大家每天讨论中的高频词。对于经验稍欠缺的同学们，刚接触领域这个词，总会感觉有点神秘。到底什么算是一个领域呢？我们经常在谈论领域模型、领域服务、领域事件、领域边界等等，如果对领域概念没有一个清晰的认识，在接受这些相关概念上想必也会遇到阻碍。本文将结合我个人的理解以及一些实践经验来谈谈对这个概念的理解，希望能帮助大家更好的认识领域，进而更好的理解和运用相关的概念，最终更好的指导软件开发实践。
中台的概念从阿里17年开始提出来就快速成为了年度IT热词。阿里这样体量的企业的成功无疑论证了中台建设的正确性，让大家对于中台这样的解决方案跃跃欲试。而阿里顺理成章成为了中台的最好代言人，大家学习中台的榜样。那么什么是中台？事实上，对于中台的定义大家也一直在探讨中。阿里内部业务系统有其独有的特点，诞生其中的中台自然也带着阿里独有的特征，这一点从《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》这本书中我们也能读出来。直接复制阿里的中台方案真的能解决广大企业中的共性问题吗？可能未必，这应该也是当前大家关于数据中台有着各种各样的解读的原因。
随着机器学习的流行，Python近几年的热度一直在上升，再加上Python本身语言设计的简洁直观和易用，Python越来越得到开发者的青睐。但是我们却时常听说Python性能低，不如java，更比不上C。在这些抱怨背后到底是什么原因呢？Python真的性能低下吗？有没有什么优化的办法呢？
对于单纯的复杂计算过程，Python性能是比较低的，这是由于Python本身在设计时首要考虑的是如何快速完成工作（get things done），所以在性能上难免会有一定的牺牲。但是由于python和c有着非常好的互操作性，这类问题都可以通过实现一个c语言的版本来解决。当然从代码编写技巧的角度也有一定的优化空间，如果我们想做极致的性能优化，可以参考官方的性能优化技巧。