面试官的话不用认真，水平一般的面试官太多了，不用跟他们较真，你会遇到各种奇葩，放轻松。

我觉得你的方向不对，没搞清楚 rx 的来龙去脉，可以看看 Erik Meijer 的一些演讲，rx 和 oo 还有 functional 不是对立的，他们不属于同一个方向的问题，没有可比性，如果不清楚它解决了什么问题就用，我觉得没有意义。

@coolair
@lycbug666

之前一直没有整理这块的架构，等我写好了分享一下，哈哈

其实总体思想就是 web 框架层，业务层和持久化层分开，不互相依赖使得它们可以轻易被替换，因为开发过程中我用了 TDD，所以每个模块必须是 decoupled，不然没法测试，然后其他的模块会有一些想 policy engine 负责对实际运营需求有不同的 policy，还有一些对接第三方服务，使得它们都可以轻易测试。

对于上面提到的 sqlalchemy 的问题，我觉得按照文档来就行了，文档提供了比较好的方向性的指点，比如 session 是 request 级的，不会被共享，我的方法是用 decorator 创建 session，诸如到 controller 中，其它的依赖注入比较类似，动态语言里真的好舒服。

曾经用 flask 写过两年的 production 级服务，自己组织了代码的分层架构，用装饰器实现相应的依赖注入，实现了 clean architecture 的六边形架构，对 sqlalchemy 也做了各种封装，感觉对于定制需求很多的人来说很合适。

自己定制可以实现更好的正交性，和 DDD 相结合，各个模块之间可以更合理的组织，曾经公司新来的同事再看到我写的项目之后都会很惊喜，认为我组织的项目结构很好的反应了业务的关系，让他们很好接手（ PS 这几个同事是 Django 背景）。

了解底层机制无可厚非，这也是 flask 在设计时想要做的，我认为不懂 wsgi 这些 web 框架原理的是不合格的开发者，这些都是一年经验就能掌握的，相反的，如果框架做的大而臃肿，用户使用时不能理解设计的理念，api 设计没有正交关系，我觉得这并不好。另外，文档过于简单的话，我没体会到，本来就很小的框架，看文档我觉得所有 api 都讲解的很详细，除非你指那些扩展。

说到文档，记得有个笑话，The Django Documentation has more words than the Bible, and I know a whole lot of them by heart. 对不起，我大学四年 Bible 都没学完，Django 的文档实在看不完。

@luger1990 基础设施服务不建议用 docker 的网络，实际测试性能差很多。

除了头条，其它用 go 的基本都是容器相关的开发，主要业务还不会用 go，另外即便头条这种，现在也都是有一部分用 java，大数据的生态还是需要对 Java 的精通。

楼上各位说的都在理，问题是人有不同，不同的人适合不同的方式展现自己，所以作为面试官要从多个方向去挖掘面试者的闪光点，刷刷题能解决那一堆 leetcode 题的人大把的有，但他们能做的可能也仅仅是刷刷题而已，很多人写不出来不是因为能力不够，只是因为一些因素不适合而已，如果面试官一定执着写不出来题的人我就是不要，那对大家来说是个双输的结局。

曾经在现场看过 Doug Lea 的一次演讲，讲 J.U.C 的，他曾经提到，他很擅长 play with machines，压榨机器的最后一滴性能，但如果让他像 JVM 那群人那样去从系统设计的角度参与 JVM 的开发，那他肯定做的很糟糕。

所以，人有不同，有些人擅长系统设计，有些人擅长面向对象设计，有些人擅长写出简洁的算法，还有些人擅长从宏观的软件工程的角度把控项目的各个 aspect，用擅长的人做合适的事情才对。

所以简单的用算法问题卡人，必然是不可取的。

脉脉上一堆大厂已经 10 点 11 点下班了，我前公司也是，直接要求在公司待够 13h，有效工作时间要超过 9.5h ，还好提前离职了，我也不差那点钱。

先别忙着下结论，你解决问题的思路就不对，目前你列出的证据没有说明进程被强杀和内存有关系，你先看看 supervisor 的 log 看看是什么原因，也许不是阿里云的问题呢？

@msg7086 看情况，美国大部分州只分两类，可回收不可回收，没有国内这么激进，毕竟大部分地区还是不发达的。

不明白，我前公司都用了两年多了，现在告诉我是新推出的功能？难度前公司的企业微信是内部版本？

#11 楼正解，java 的 microbenchmark 很重要，做跑分一定要有足够的预热，不然你测出来的结果是比 python 还慢，然而真实情况并不是这样，microbenchmark 是 java 开发者的基础。

TCC，最终一致性，2pc 对业务不透明而且实现难度大，https://queue.acm.org/detail.cfm?id=1394128 参考 BASE 模型

前天打电话约了今天下午的面试，然后就没有然后了，是因为感觉我没有方案可以套？

楼上几位说的太过绝对，单元测试的单元如何去区分太过绝对，不是说只测一个方法或者一个类，这个没有一个绝对的准确的定义，各种讲单元测试的书诸如 Clean Code 和 The art of Unit Testing 几乎都提到了要根据具体业务来区分，有绝对第三方依赖的应该 mock，如数据库，sdk 等，我一般都是按照业务需求来测试，不然每个方法都要测试的话，工作量太大而且没有什么意义。

回到楼主的问题，也是要根据需求区分对待，有些模块对正确性有要求就应该测试结果，有些模块只是调用了一些第三方系统或者持久化依赖，那只需要测试过程就可以。

CAS 的表现极度依赖硬件平台，如果处理器很多并且竟态条件严重的情况下，CAS 的开销也会很大，Oracle 官方曾经有文章研究过这个问题，另外，synchronized 的锁升级情况也要考虑，在不同竟态条件下锁的开销不一样，这个楼上已经提到过了。
再说一点，你的测试方法有问题，没有预热，这种测试正规应该用 jmh 来做，在不同的系统 load 情况下，performance 会有很大差别。

你说的这些问题是典型的 DDD 解决的问题，限界上下文和聚合根，如果之前没有了解过，可以了解一下。
另外，问题 2 中不符合设计模式原则我有点懵逼，哪条原则？

@Raisu 丹尼斯 - 里奇

@SimonOne 嗯，他工作经验多，又曾经是淘宝资深员工，领导比较信任他，好在后来那个服务越来越好了，没有继续烂下去。