一周技术思考（第16期）-通过[洋葱]看服务和架构
大家好，这里记录，我每周碰到的，看到的，或想到的，引起触动，或感动的，技术事物的思考，不见得都对，但开始思考总是好的。
通过“洋葱”看服务与架构
我们要了解服务的行为，尤其是大型应用环境下，会有以百计的服务数量，那么我们势必要为这些服务做好配套的监控系统，这些监控系统的数据来源都是一个个的服务粒度的环境下产生的。
比如一个查询订单的微服务，我们要看每次查询订单的数据量，这个可以叫做业务指标；我们要看这些数据是谁查的，什么时间查的，这个可以叫做应用日志；我们要看每次查询的性能怎么样，比如TP99值是多少，这个可以叫做运维指标；我们要看每次查询数据的时候网络IO是多少，TCP重传是多少呢，这个可以叫做基础设施指标。
所以，先前说的监控系统的数据，都是由这些指标数据得来的。那么，这样一层又一层的围绕着这个查询订单服务的这些层，是不是有点像[洋葱]那样呢，洋葱的最里面是我们的服务，然后外面的每一层是我们监控系统所要的指标。如下图所示。
图自《微服务实战》1.3章节内容
一个业务功能的微服务由多个工具层（负责产生监控指标数据的）所包围。请求会穿过这些工具层送给微服务，而返回的结果也会穿过它们发送出去，这个过程中所收集的数据也会存储到一个运维数据库中。
这便是我们今天用“洋葱法”来看待我们实际工作中的大家已熟知的微服务监控，给工作找点乐趣，换个想法看事物。
咿呀，如果按照这样的说法，那我以前看到的整洁架构那个图，不也是个洋葱吗，来，我们一起再看看。
图自《架构整洁之道》第22章内容
其中最里层是我们的关键业务逻辑，我们都已经知道是不应该让外层圆中发生的任何变更影响到内层圆的代码，最中心圆层封装了最通用、最高层的业务逻辑代码。
从最里层开始，依次往外，是我们的用例层，这层包含了我们的特定场景下的业务逻辑，如果你能够跟开闭原则结合起来，这层是“开”，刚才最中间那层是“闭”。
然后是我们的接口适配器层，里面包含诸如图中的网关、控制器等一些”转换器“，负责将数据从对用例和业务实体而言最方便操作的格式，转换成外部系统最方便的操作格式。
最后到了最外面一层就是我们的框架、工具、数据库、web框架等等，在这一层我们通常只需要编写一些与内层沟通的粘合性代码，毕竟业务逻辑早已被沉淀到了最底层。
你看，我们又用洋葱分析了整洁架构。
那，六边形架构呢，是不是圆环套圆环的都是这样的，对于六边形架构，我贴一张六边形的图出来，然后呢，建议大家可以按照上面“剥洋葱”的方式自己来尝试剥一剥，分析分析。
图自《实现领域驱动设计》第4章内容
“横看成岭侧成峰，远近高低各不同”，山虽还是那山，但是对于我们已经熟悉的老事物，如果感觉有点“疲惫”了，不妨换个角度来看待和思考，这样可以给你带来一些新的思考方式，说不定能带来新的灵感。
换一种角度看待老事物
是的，换一种角度看待事物是会给你带来新鲜感的，比如我们非常非熟悉的接口这个东西。
我们都知道，面向对象编程的时候建议我们要面向接口、面向抽象，为了将来的扩展性，大家一定要这样做，我们是这样强调的吧。另外还不忘加一句，依赖倒置原则就是这种开发方式的意识与形态相结合的载体。
来，今天我们换个角度思考，我说面向接口/抽象编程是为了做好隔离，为了隔离修改。你先记下，我继续讲。
我们的需求是不停改变的，正常情况下，我们的代码也会随着改变，对吧。我们也知道具体类包含了实现细节，而抽象只呈现了概念。如果使用者依赖了具体类，也就依赖了具体细节，当细节改变时候，使用者就会风险。
那好，我们便可以借助接口和抽象，也就是依赖于抽象编程，就可以隔离这些细节带来的影响，不是这样么。
你看，山还是那山，换了一个从隔离修改的角度来看待面向抽象编程，是不是跟之前有点不一样了呢，当然，本质没有变化，只不过呢，我们换个角度看问题，我们的思维更打开了些，不好么。
关于面向接口编程，我再抛出一个新角度：降低连接度，大家可以尝试从降低连接度的方向自己分析分析呢，对还是分析“那座山”。
新功能是在原有系统中添加还是另辟一个新服务
其实有些行业是比较厌恶风险的，你比如说金融行业内的公司，他们都受到严格的监管，他们更倾向于构建一套自上而下的变更控制系统，通过软件变更的频率和影响范围来避免某种可能出现的风险。
很久之前我给银行做项目的时候，他们就很保守，有的系统都用了很多年，只要没有问题，仍然继续使用，现在我不太清楚是否有改变，了解的朋友可以说下自己的看法。
那这跟我们这个主题有什么关系呢，我们说的是到底是在新系统添加一个功能，还是另外开辟一个新的服务，其实本质都是一样的，就是到底要怎么样变化，怎么幅度的变化。
在以前大家经常所说的单体时代，我们可能也会有这样的问题，但是呢，它们的意义并不相同，因为部署一个新服务所要花费的时间和精力肯定要比在原系统创建一个新的模块更大。可是，在微服务时代里，早已不存在创建一个新的服务的难度的问题。
随之而来的新的问题是，我们划定微服务的范围时，我们要确保拆分系统所增加的复杂度不会超过所带来的益处。
我接下来用一个新的主题内容来继续延展这个问题。
我应该拉大旗搞一个新的应用工程吗
只要你干过两三年编程，就有可能曾被某人的糟糕代码绊倒过。
对这个绊倒的理解可就丰富了，写出了bug导致了线上的事故，影响了工作效率拖了项目工期的后腿，对每次的需求修改总是影响到别的几处代码，这样的闹心的乱麻越来越大，随着这样的混乱增加，团队的生产力也持续下降，趋向于零。
图自《代码整洁之道》1.3
这些现象和结果都说明被“绊倒”的不轻。
既然老的代码这么糟糕，我就跟老板申请，我要重新搭建一个工程，然后在这个新的工程上面支撑我们的业务需求。是呀，谁不想在干净的白纸上写代码呢。
但这样做有一个你要面临并必须解决的问题，新搭建的这套系统代码，要具备两方面的能力，一方面是要支持所有固有的功能，一方面是新增加的功能。其实还有第三个方面，也是最重要的，搭建一个新的工程还必须要能够追赶上旧系统的持续改动，毕竟搭建新系统是要有工期的。
结果就是，两只团队开始竞赛，你觉得这样可取吗，往往这种竞赛持续的时间都是比较长的。我们总想新搭建系统，哪里又有这样新机会呢，毕竟历史上已经存在了那么多的代码，总有人来维护吧。
我个人建议，对老的系统中待改进的地方进行梳理出一个列表，并做轻重缓急分类，每次迭代中呢拿出20%的部分进行修改，依次持续的推荐，切莫进行推倒重来的一步执行。
根据历史经验，不这样做，后果往往很严重。那么这也警醒我们一定从开始就要保持代码的整洁。做一名有“代码感”的程序员。
缺乏“代码感”的程序员，看混乱是混乱，无处着手。有“代码感”的程序员能从混乱中看出其他的可能与变化。“代码感”帮助程序员选出最好的方案，并指导程序员制订修改行动计划，按图索骥。
如何对遗留系统的服务改造意愿进行可视化
遗留系统属于既得利益范畴，不出问题，不出大的问题，不让你感到痛，不让你感到很痛的时候，一般没人愿意去主动的折腾那些老代码，你不信，那你回想回想自己的工作研发经历。
但是，这个研发世界里毕竟还是有追逐梦想的人，愿意做一个有追求的研发者，另外，主动即自由，放在这里也合适，当老系统爆发出问题，找到你的时候，想想那个时候，你会有多被动，一方面要解决线上问题，一方面要回复老板的责问，曾想如果当初我下定决心将其分步治理，情况不至于此，但为时已晚。
如果你愿意做这个主动者，想对老系统开刀，那么你面对的可能不仅仅是一个服务，甚至不仅仅是一个系统，也可能是一个系统里面的多个服务，这些不同的服务，又有不同的人来维护者，这些维护者要动刀的意愿有多强呢，作为主刀的你要想办法给量出来。
怎么量，要是能够用数字展现出来该多好，殊不知这样的方式，可行，也肯定可以行。下面这张图（刚好我也拿到了当年公开版的PPT，如果你想更详细学习，可以加我微信索取），就分别从业务复杂度，需求变化频率，使用频度，系统集成关系，数据迁移量，代码改动量这些维度去量化每一项的“程度”，比如业务复杂度，满分10分，现在是8分，那么就属于业务较复杂的项。
图自 2019年 DDD China 大会 毛超
按照这样的维度与方法逐一分析，就会得出一个按照业务维度和技术维度两种维度下的总体改造“难度值”，或者是”意愿值“，因为纵使难度值再大，只要意愿值不低，也能成事，把控好风险即可。
本周完，下周见。