欢迎来到文思源想的架构空间，前段时间博主做了一个工作经历复盘，10年开发路，走了不少弯路，也算积累了不少软件开发、架构设计的经验和心得，确实有必要好好盘一盘，作为个人的总结，同时也留给有缘读过的人，带给一丝启发或者少走一点坑，都是好事。于是有了这个文思架构笔记这个专题的想法，未来会陆陆续续梳理一些自己总结的东西和正在发生的事情，作为留存，也作为纪念。今天是第一篇——关于剃刀思维！
“如无必要，勿增实体” ，这句话来自奥卡姆剃刀原理的核心说明，针对云服务架构它也是非常必要。老子说大道至简，亚里士多德说自然界选择最短的道路，产品交互设计也有个理念叫less is more -- 少即是多。它不只是告诉人们要做减法，而是更多去思考我们实现功能外引入新的复杂度和问题，充分考虑和权衡。
在云服务架构演进中我们看到了许多演进共同的现象，为了多活我们引入了多活控制器，为了一个新增业务避免老功能受到影响，采用新增服务的方式隔离变化，为了调用尽量少的改动，我们将一个请求扩充到五六跳甚至更多。但是做法却同时也带了一些新的影响：
- 首先服务调用链路更长了，这引入了更高的服务治理复杂度，我们不再是简单几跳解决一个请求，而是更多的中转也带了更多定位问题的复杂性，功能实现或许改动小了，但是未来压测、定位复杂问题更多了。
- 其次引入新服务和模块，拆分微服务，更多的其实应该考虑的是业务的解耦，功能的复用，而不是站在小组的角度，考虑什么好做把几个功能聚合在一起，微服务架构设计虽然必然走向康威定律的方向（组织结构决定代码架构），但是实际上是需要有人做好评审和管控的。新增服务并不一定是好事，这个事情是需要评审和确定的，或者做一做减法，常常问一些新的问题：
-
- 如果不要新增，是否能完成功能；
- 如果新增服务带来哪些运维架构、安全、服务治理的隐患；
- 是否还有其他更好的解决思路。
接着还有多活这个话题，通常多活在云服务架构里面有多种拆分方式，集群方案和多活控制器，当然采用上游负载均衡hash或者一致性hash找到下游服务的方式，这无疑是最常用的解决思路，但是他的问题也同样多：
- 服务实体增多，部署复杂度、部署规格要求逐步放大，以前可能一个服务搞定的事情现在可能需要两个或者三个，这里是实打实的成本上升，私有云环境下以前可以四五十核搞定一个环境，而如今不下数百核一个最小系统都不能完备。诚然我们功能在增多、业务在复杂，但是我们每套云的用户数、规模并没有增大到数量翻倍的情况，这里的问题就是引入实体，但是没有做减法，没有定期回顾，看看哪里不合理。
- 服务发现、服务间通信问题变得更加紧密，定位问题也成为了一个难点，再加上某些开源软件在调用链上的特殊性，导致治理和灰度成为了很棘手的问题。
最后我想到的则是设计和建模中的抽象，通常通过业务场景分析、用户动作行为拆解，我们会在概要设计中产生许多概念，但是落地的时候实际上是需要区分什么是视图层什么是核心层模型的，把变化留在视图层，而核心层模型的定义，我认为是要经过头脑风暴和反复核对的：
- 把多余属性拆解到极致，去除掉一切冗余字段
- 反思如何把业务用几句话说清楚，弄清楚关键模型和关键动作，然后还能看到未来的变化，以及未来我们怎么应对变化
虽然他们不全是领域驱动设计，但是也包含了领域驱动的一些思想。分析业务场景时候由少到多，遍历细节，建模归纳时候由多到少，用核心模型、动作，充分裁剪，最后通过考虑特殊情况，补充场景。最后的最后就是问一问能不能少一些实体，少一些不一样的接口，能否复用。
总之，接口、模型、字段、调用、服务、业务他们都是所谓的实体，如无必要勿增实体，我们设计时候就需要考虑这些实体存在的必要性，同时反思是否会带来影响其他必要实体的问题。功能实现简单性只是一个新增的理由，我们更多想想未来治理的代码，部署的复杂性，额外新增的机器和研发消耗更多的精力，以及冗余引起的争议和误会。我们不仅要实现功能，还需考虑业务的解耦，更要考虑实体的熵增。人熵增需要断舍离，软件系统熵增则需要重构，盘点、分析、归纳合并、设计、重构，这个事情是需要持续进行，是需要自上而下倡导，最终最下而上显现。
当然剃刀思维还有一个关键，就是我们有他，但是最好不需要它。当一个不需要的实体存在，这个实体就会开始证明自己存在的必要，其他原来必要存在的实体也会因为他的存在而容易自发建立一套与它有关的新协作或者新习惯。老业务会通过新部门形成砍不掉的冗余流程，豆浆机也会在你买菜时候提醒你多买一些吃不完的豆子，这个时候在用剃刀就很难了，剃了就会很疼很受伤，然后就需要权衡有了犹豫。勿增实体而不是剃掉实体，是因为剃刀思维的关键是一开始就找到这些不需要的实体，防患于未然，所以需求评审、架构设计、模型设计、调用流程设计都需要有这样的思考和审核，从一开始就找到这些没有必要存在的实体。
剃刀的真意在于止“繁”存"简" ----心存一刀，只留必要，心中有刀无需用刀，才是最好的状态，或许这是必字的另一种解释，也是我们设计架构的一个需要重视的要诀。
