你好，我是郭东白。上节课我们学习了马斯洛关于人性的理论，那么这节课我们就利用这个理论来看看我们在架构活动中应该注意些什么。
架构设计必须符合人性，而在架构活动中，与“人”相关的主要就是研发人员和目标用户。那么今天这节课我们就先从研发人员讲起。
想想看，如果架构设计忽略或剥夺了研发人员的人性，会怎样呢？再一个，如果架构活动中尊重和顺应了人性，那么又能给我们架构师一个怎样不同的解决问题的视野呢？这正是我们接下来要讨论的内容。
环顾四周，你会发现研发人员对安全感的需求很是强烈。内卷、35岁危机、996，各种流行关键词似乎都指向了安全感的缺失。为什么会这样呢？
我们刚刚学习的马斯洛理论这时候就可以回答了：因为我们都吃得太饱穿得太暖了！我们的生理需求得到了充分的满足！这么一来，心理安全感的需求就赤裸裸地暴露在那里，等待着被满足。
这个答案是半开玩笑的。不过一般情况下，大多数研发人员的生理需求的确不在架构师的考虑范围之内。顺便说一句，有极少数公司会利用人的生理需求来获益，比较阴暗。我唯一的建议就是，远离做这种尝试的公司，在这个时代你有更好的选择。
好了，言归正传。研发人员的生理需求是能够在软件架构考虑范围之外得到充分满足的，那么根据马斯洛的理论，如果一个研发团队，本来是具备心理安全感的，但是突然间却被剥夺了，这会导致什么问题呢？
接下来，我们就通过一个案例来演示一下，研发人员的心理安全感被破坏之后会造成什么损失。
我曾受邀给一个在行业内处于垄断地位的大企业做架构规划的外部评审。这家企业的技术在自己所处领域内领先全球，加上资金雄厚，因而他们开始在海外做布局，投资了一家同领域的初创公司。
本来小公司有自己的研发人员，且初步建设了自己的技术体系，基本可以支持本国的业务。但在大企业看来，这家小公司的技术落后自己几年，而且研发人员的能力也有限。
在这个背景下，大企业的国际化团队提出了一个架构设计，如下图所示：
这张图略去了很多细节，不过完全保留了这个架构设计的本质。
投资前，小公司有自己的完整技术栈，如图中左边部分所示。但投资之后，大企业期望小公司能把他们的技术迁移到一个由自己开发的技术平台上去，这样大企业的部分技术就可以通过平台输出给这家小公司了。
这个技术平台主要包含两部分：
如果将小公司的技术迁移到本地技术平台之后，他们的研发团队就可以集中关注怎么在本地技术平台上开发自己国家的解决方案。这样一来，之前做本地平台功能的研发人员可以减少很多。而且由于对本地解决方案开发者的技能要求相对更低，这样的研发人员很容易找到，那么用人成本也低。
此外，这样做还有几个附加的好处。首先，大企业开发的本地技术平台基于全球最先进、业务体量最大的中国市场的技术建设，所以不但技术先进，而且附带了很多海外同行们还没有开发出来的业务能力。
其次，本地技术平台和大企业的全球业务网络是打通的，所以小公司一旦接入本地技术平台，那跟它就和全球业务网络一下子就完全打通了。额外的生意滚滚而来，成本又少了很多，何乐而不为呢？
但结果呢？
一年后，大企业投入几千人终于建成了这个庞大的系统，也大幅扩招了在海外的投资版图，但能接受这个方案的小公司却寥寥无几。第二年， 大企业又做了一次全面的技术升级，放宽合作条件，增加对部分小公司的投资占比，但技术方案的推进和被投资业务的增长都不尽如人意。又过了一年，这个方案最终被取消了。
四年后，行业蓬勃发展，但大企业投资的小公司完全没有像期望的那样复制了大企业在国内的成功。不算小公司侧的研发损失，仅大企业损失的研发资源就达到了1.5万到2万人年，再加上直接投资，损失高达几十亿美金。这还不算浪费掉的机会成本。
为什么会造成如此惨重的结果呢？
因为这个架构设计完全忽略了人性。具体来说，就是这个架构方案完全忽视了小公司里研发团队的心理安全感需求。
想想看，如果你在小公司任职，你研发了第一代技术，让公司被一个资金雄厚的国际化大企业看中。但随之而来的就是把你辛苦开发的代码全部下线。紧接着，你的日常工作就变成了跟第三方供应商做系统对接，与核心技术失去了接触。这个方案一旦采用， 那么一夜之间，从CTO到一线研发，每个技术人的安全感都被一扫而光。这个时候你还会安心地留在公司吗？
或许你会说，如果小公司被大企业收购，肯定会签约保留老员工，用股权机制拴住他们。这样一来，他们肯定可以完成技术迁移，不是吗？
正如我们在上节课所讲的，依照马斯洛模型，心理安全感是一个人的内在需求，只有这个内在的需求被完全满足了，它所诱发的动机才会消失，否则这种动机将持续被诱发。所以, 虽然外部激励的确会诱导员工的行为，但却不能从本质上满足已经被剥夺的心理安全感。在这个软件开发人员相对能够保障衣食无忧的年代，没有比获取心理安全感更高的动机了。
让我们再来回忆一下上节课讲的马斯洛的动机跃迁模型：
一个动机一旦进入了主导状态，那么这个动机就会召唤一个人的全部能力去满足这个动机。在这种情形之下，你整个人，包括你的视觉、听觉、嗅觉，你的思考、记忆、行为等等，都只有一个目的，那就是满足这个动机。
现在你应该知道了，获取心理安全感必然会成为小公司研发人员的主导动机。假设你在小公司工作，在拿到技术方案后，你的第一优先级会是去完成技术迁移吗？哪怕有股权和激励诱导你这么做，你会全身心地投入其中，保障迁移迅速完成吗？ 至少马斯洛不这么认为。
如果把这些被投资的海外小公司的研发团队比作一个人的话，那么我们在“案例背景”部分看到的那张架构设计图，无疑是断了他的生路。在这种新架构之下，研发团队根本没法创造出任何可以让自己长期被企业依赖，也就是保障自己生存的长期价值。我们甚至可以继续推演一下，当一个小公司的非研发人员发现自己公司被收购之后，所有的核心研发人员都开始陆续离职，那么他们自己的心理安全感还是硬杠杠的吗？
虽然从技术角度来看，这是个非常有价值的架构方案，但这却是一个完全没有人性的架构。一个完全忽略了研发视角的设计，不但没有从共情出发，甚至是践踏了人性。那么这个架构在海外屡战屡败的事实也就不证自明了。
因而这个例子告诉我们，你作为一个架构师，设计的方案必须要尊重研发同学的人性，一个完全忽略人性的架构是没有生存空间的。
再回到这家国内的垄断大企业，你可能会好奇了，为什么这种没有人性架构竟然能够横空出世？为什么这种方案在屡战屡败的情况下竟然还被整整实施了两年多呢？
在邀请我去做架构评审的时候，这家大企业的研发已经有五千多人了。而拿到那次架构评审会议上的项目，也就不到十个。那么每个项目动辄就是数百甚至上千人参与。
这个国际化技术平台的项目，也有好几百人研发人员的参与。虽然是项目评审，但是拿到会上的时候，项目已经启动了。不只是架构师，各方参与人员早已排列整齐，甚至部分研发工作已经启动了。
在架构评审会上，我曾经极力劝阻这个项目的架构师和相关的研发主管，期望他们能放弃这个设计。但最终没能说服他们。
为什么要劝他们放弃呢？因为马斯洛的理论也在这个时候起作用了！
所有已经在这个项目里的人，他们的升职、团队招聘、晋升、年终奖、股票都已经和这个项目牢牢绑定。对于他们而言，任何动摇这个项目稳定性或者是削弱这个项目价值的言论，必然会伤害到他们的自身利益和心理安全感。
同样，在这个时候，他们获取心理安全感的动机也会主导他们所有的感官、意识和行为。所以项目里的人会拼命维护他们的立场，就像小公司里的研发人员一样，他们都在为获取自己的心理安全感投入全身心的努力！
结果就是项目评审会并没有对项目的状态产生什么本质影响。项目启动之后，在国外的接连挫败也没能让参与者们从根本上改变这个架构，因为他们就是这个国际技术平台下的一个衍生物种，让他们去破坏自己赖以生存的空间，完全不可能。更现实的是，越到项目后期，大家的利益和平台绑定得就越深，越是难以阻止。
也就是说，在那次评审会上，这个项目因为前期投入太大，参与的人太多，项目已经不是箭在弦上、不得不发的状态，而是离弦之箭，驷马难追。单靠一个项目评审会，很难把这个项目拉回来。
你看看，马斯洛的理论是多么美妙，又是多么对称的一个理论啊！这个理论不但解释了受迫害一方的行为，而且也完美解释了施虐方的行为。这是个多么讽刺的场景啊！
现在让我们再次强调一下今天讲的生存法则：架构活动需要尊重和顺应人性。架构师必须洞察研发人员的人性，在方案设计和架构活动组织中充分考虑研发的人性，才能保障方案的正确性，以及方案的高效实施。
如果说我们还能从这个案例中能得到什么额外认知的话，那就是：越是大型的架构方案，就越要在早期去讨论它的方案可行性，而且要尽量试图要从批判和否定的眼光去看待它。这种讨论越早越好，涉及的利益方也越少越好，而不是放在详细规划已经完成之后，甚至是项目已经了启动一小半了才做评审。
那么你可能会问我，但是为啥要这么长的时间大家才意识到这个方案是不可行的呢？难道不能上线半年内就终止，减少损失吗？
从某种层面上讲，当一个架构方案有数千人参与，那么这个方案随着时间已经逐渐演变成了一个运动。一个运动，由这个运动自身而产生的惯性，已经不受一两个决策者控制，大量的参与者已经为这个运动注入了持续的生命力。
这个惯性是非常令人恐惧的。而惯性的根源就在于马斯洛的人性理论中的生理需求和心理安全感，这是一种参与者哪怕有认知都很难抗拒的心理。在参与者人数足够大的时候，这种内在的驱动里就很难从外部被影响。这也是为什么我认为人类历史上有一个又一个从悲惨的开局一直持续演到悲惨的结尾的长剧。
当然，马斯洛理论的应用还不止这些。如果架构活动尊重和顺应了人性，那么又能给我们架构师一个怎样不同的解决问题的视野呢？
微服务有个永恒的话题，就是微服务的粒度到底该怎么定。一个人应该分到几个微服务，还是几个人一起维护一个微服务呢？
对于这个问题，我想你肯定听到过各式各样的答案。有讲3个人维护一个的，也有说应该两个人维护一个的，还有说一个人维护一个的。那么现在让我们来假设一下，如果是马斯洛马老师，他会怎么设计微服务的粒度呢？
“根据您的理论，同时考虑到现实情况，微服务应该不能只满足研发人员的生理需求，对吧？” 我断言道。
“是的，所以安全感对一个研发人员就很重要了。那么我们应该怎么划分微服务，才能让每个研发拥有最大的安全感呢？”马老师问我。
我想了想，回答道：“每人至少一个，而且还得是核心服务”。
“为什么呢？”马老师继续问。
“这样每个研发都不用担心他的工作安全，因为没有人能够轻易取代他。”我老实回答。
“还不止这些好处。如果这么划分，也会给予每个研发以自尊，因为他们对自己的微服务拥有完全决策的自由，这相当于给了他们自信和勇气。此外，他们能从服务他人的过程中感觉到自己是被需要的，这就又给了他们成就感。自尊和成就感，这两者都是有底气的自尊的源泉。更进一步讲，如果说他们的微服务能帮助一家公司更好地服务社会，那么他们甚至能在自己的微服务中找到自我实现的价值！”
“想不到马老师对微服务这么有研究啊！” 我的敬仰如滔滔江水。
“哪里哪里，我只是看透人性罢了。”马老师谦虚地回答我。
当然，划分微服务的粒度不仅需要考虑研发的人性，还要考虑服务本身的原子性、团队大小、团队人员的稳定性、服务的高可靠性要求等等。不过单从人性角度思考，如果你独立负责一个核心微服务的话，那么你的安全感和自尊都是最大化的。
举个现实中的案例，我们来验证一下。在阿里时，我们部门的人均服务数是1.5个左右，而淘宝是不到0.3个。我们团队的人均代码产出是淘宝同学的三倍，代码质量指标千行代码的缺陷率是淘宝的一半，人均日发布次数是淘宝的7倍多，发布成功率和淘宝持平。
当然，两个业务的体量和复杂度完全不能相提并论，而且稳定性要求也不一样。所以直接推导出人均服务数越多越好的结论也不合理。
这是从研发ROI的角度来思考微服务粒度的问题，我们还可以从微服务本身的设计出发来思考。微服务的核心价值在于以下几点：
其中第1、2、3项是人越少越高效的，最高效的状态就是一个人。想想看，你自己对业务有深度理解，能够和业务同频率迭代。你什么时候想改代码就改代码，不需要协同，改好了就上线。你自己一个人改自己的商业逻辑和数据模型，根本不需要担心其他人祸害。
在这种状态下，你的速度绝对是最快的。而且就你个人的能力为极限，也是协同越少，你能产出代码的质量越高。所以从这个角度来说，让多名研发维护一个微服务的配置是不合理的。
唯一能够支持多名研发维护同一个服务的理由，就是服务本身对公司的价值太大，它上面承载的业务量，对稳定性的要求，对服务连续性的要求，大到可以忽略研发资源的成本的时候；或者是从性能角度来看，服务无法拆分，它得复杂度大到可以支持多个研发维护的时候。在这种情况下，多个研发维护同一个服务的布局才是合理的。
这种布局在年交易额超过万亿美金的淘宝平台，其实是说得过去的，尤其在中国这种互联网研发人员供给相对充沛的环境之下。
但是，我们大多数人所在的公司并不是像阿里腾讯这样处于垄断地位的互联网公司，甚至哪怕你在阿里和腾讯，你也很可能不在公司最主流的现金流业务中，那么多个人维护一个服务的配置，我认为就不合理。
当然，有些人认为一个服务上只有一名研发会有稳定性风险，我觉得这个理由不成立。微服务的隔离性和有分布式架构带来的稳定性，是能抗住个别同学离职的压力的。而且服务粒度越小，这种承受能力越大。
我曾经经历过一家公司一个月内有15%的研发人员离职的情况，而且这家公司的服务数和研发人员数之比远大于一。但即使是在这种情况下，最终也没有发生稳定性大崩盘的情况。所以以稳定性为由来扩充研发人员，我不认为这是一种好的策略。事实上，比这好的提升稳定性的办法有的是。
其实我一直认为做微服务就像农民耕耘自己的土地一样。无论是古罗马，还是中国封建社会的历朝历代，再或是美国，开国之初都有过开荒屯田的政策，每个农民都可以分到一块属于自己的土地，国家也因此得到了飞速的发展。
对于我们今天这些进城的互联网民工来说，微服务就是咱们的土地。有了自己的地，我们肯定会拼命劳作，想办法从土地里找到致富的希望，不是吗？ 但是如果大家都在一个大锅盛饭吃，而且总是僧多粥少，曾经挨过饿的互联网民工们能不担心吗？
通过今天讲的这两个案例，我想你不仅知道该如何理解马斯洛的人性理论，而且还知道该如何应用了。正如我反复强调的那样，或许你学完这些法则会觉得内容太过简单，但就是这些最基本的原理，其实对结果的影响和对效率的撬动才越大。你用对了这样基本的理论，就可以带来成倍效果提升；而用错了，或者忽略了，则会带来灾难性的损失。
所以越是一个看似简单的道理，其实越需要你运用这个道理去深度思考自己身边发生的事情，从而看清事物的本质。听说过原理不等于懂，懂得原理而不会用，就等于入宝山而空手归。而原理用得多了，事情的本质也会看得更清楚。
那么下节课，我们将从用户的角度来继续探讨人性。
三个作业，任选一道：
在第一个案例中，我还听到过这样一种说法：大企业的CEO肯定会支持这个项目，那么我们派进去的人进场完成迁移就好了。真的可以这样吗？你能否从CEO的视角来看，这种说法违反了马斯洛理论的什么动机和需求层次？如果你是CEO，你会从内心里接受这个架构方案吗？为什么？
从安全感的角度来看，许多企业经常把“拥抱变化”的价值观挂在口上，但这其实是反人性的。拥抱变化，也就是在变相要求员工去接受一个他们不连续的、不安全的、不一致的，甚至有可能是不公平的处境。你是怎么看待这个问题的呢？这个观点正确的部分在哪里？错误的地方又在哪里呢？在什么情况下，拥抱变化是能够成为员工发自内心所认同的价值观呢？
影响微服务粒度的决策还有不少其他因素，你如果有其他的理由或者完全不同的角度来得出你的结论，也欢迎你把你的想法分享给大家。
欢迎把你的想法和思考分享在留言区，和我一起交流。相信经过你的深度思考，知识会掌握得更牢固。