架构师日常-架构设计

Posted 2022-11-20 Q博士

阶段

• 0-1的架构设计
• 1-N的架构优化

0-1的架构设计，这种场景很少碰到，这种是没有历史包袱的，这种是很考验架构师的专业能力，需求理解能力，还要做好产出收益比的衡量。
1-N的应该经常遇到的，目前的互联网氛围，在业务开始阶段都是求快，不会考虑架构合理不合理的逻辑，所以一旦业务起来后，架构优化就随之而来变得迫切。

在现在的公司，我做过2次0-1的架构优化，3次1-N的架构优化。目前就在当前业务线做架构优化，接下来我主要讲当前的1-N的架构优化，不对0-1进行阐述。

优化点

首先从代码逻辑进行分析，那就得首先大致review下代码逻辑，不是纯codereview这么耗时的工作，像我们的微服务架构，一共有接近20个模块，codereview不太现实，所以我主要想得到各个模块之间的调用关系，以及依赖哪些第三方。当然业界普遍会用trace系统分析得出，但我们暂时还没接入，所以采用最原始的方法。

好在这些模块在代码分层和代码文件目录的结构上是统一的，所以很容易就能得到依赖哪些RPC请求，可以得到一个模块依赖哪些第三方。这些分析拿到手后，我们大致也就知道了哪些功能是重复的，哪些功能的提供时不应该的，也就是功能划分出现问题，比如订单中心提供了用户中心的功能，大致发现的问题如下

• 底层服务之间存在相互调用情况：比如A调用B，B也调用A，但是从架构上来看，他们直接不该有调用关系，这个情况同时犯了2个问题，一是不应该有调用，二是不应该相互调用。
• 多处调用一个第三方依赖：比如A模块调用了高德的轨迹服务，B和C模块都调用了高德的轨迹服务，那我们应该统一收敛到对外网关服务上
• 基础服务没有划分：统一的导出任务写在了订单中心，没有统一的上传功能，操作日志写在了用户中心上，所以这个应该其一个基础服务模块，将这些功能全部迁移过去。
• RPC协议收敛：我们RPC用了2个，feign和dubbo，比例为7：1，也就是很少的几个模块用了dubbo，所以要收敛为一个，要么全部feign，要么全部dubbo，基于公司基础架构和我们熟悉程度，我们最后决定放弃dubbo，这个没有啥技术选项，只是出于我们当前的情况决定的。
• 依赖一些不稳定的服务：比如我们要废弃的点召回服务，我们还在用公司一代产品tile38，后来我们切到es，但是我们还没切
• 相同功能接了不同的第三方：比如地图服务，有百度和高德，还有自己内部的，我们可以对接多个服务，但是不能是垂直划分，而应该是横向，让另一个作为备份，所以优化方向是全面切高德，然后百度作为备份，当出现问题后，自动切换到百度。以及短信服务，我们也有类似情况
• 模块划分不清晰：就是我们微服务模块中每个都有功能划分，不能出现跟不符合该模块定位的功能，所以如果出现在A模块中开发了B模块，那就是有问题的，所以也需要迁移回去