如何在分层架构与微服务之间做出合理的选择？

最近似乎所有的电台里都在为国庆长假倒数计时，身边的小伙伴们好像也提前进入了庆欢状态，连我也提前一周打点好了潜水装备，耐心等待那黄金一刻的到来

按照惯例，每年十一黄金周是公司启动下一年战略规划的触发点，对于 IT 侧来说无非就是谈谈架构，算算成本，拢拢人头

既然是谈谈架构，必然会谈到技术改造的话题，比如某某系统的改造，某某系统的重构之类，而且改造（或重构）可以给公司将来带来如何如何的好处和收益，这些其实都是司空见惯的事情，可就在讨论的过程中，由于某系统的改造方案，引起了一场小小的争论……

故事情节回放

故事场景：A 系统，负责公司内部的信息化管理工作，疑似 “OA+资源管理+DevOps（部分）” 的综合性功能类系统

故事背景：由于业务迭代多，速度要求提高，导致 BUG 增多，效率下降，所以决定对 A 系统进行服务拆分

改造目的：

迁移：DevOps 类功能迁移至 PaaS 平台中

拆分：业务垂直拆分，解决改 A 错 B

分层：建立自定义中台，支持大量自定义流程更改并同时快速迭代的需求

资源投入：架构师 1，开发 3

时间要求：1 个月内上线，同时保证正常周迭代需求陆续上线

技术指标：在线<200 人，稳定性要求高

题图：A 君 = 系统架构设计概要图 - 采用 Dubbo 作为 RPC 技术选型

说完情节，回放以下部分对话（A 君 = 架构师）：

……(完成对改造方案的说明)……

A 君：大家看看，对这个方案有什么问题吗？

B 君：我感觉没必要拆的那么细吧，不就内部系统吗？又不是在线联机服务，把代码分层做做好，也可以放在不同的 Project 里，表在一个库里用不同的前缀区分业务，获取数据也变得更简单了

题图：B 君 = 系统架构设计概要图 - 代码分层，JVM 内部方法调用

A 君：你这么设计有问题的，问题如下：

如果 A 模块变更，怎么才能独立发布呢？

再如果 B 模块方法入参变更，影响到 C 模块怎么办？

再如果 D 模块因为某某原因导致流量增大，不是把其他功能都拖慢了吗？

再如果 E 模块出现一个 BUG，不是把整个系统都 Crash 掉了吗？

再如果数据库挂了，不是整个系统都不可用了吗？

再如果……

A 君：刚才说的是系统结构，再说说人吧，我们几个都不太会前端技术，只有张三会前端，所以如果按照我的架构设计，我打算把整个表现层都交给张三做，独立的 War 包服务，想怎么玩，想怎么发布都行

A 君：何况外面的系统都是这么玩的，我不觉得我的设计有什么问题，你这个设计太落伍了吧，不利于未来的扩展性、灵活性……

……(略过很多行，不过到这时，B 君已经不再说话了)……

在做出合理的选择之时，我们该考虑些什么？

接口规范远比扩展性与灵活性更重要

相比系统的扩展性与灵活性，接口输入、输出及接口命名的规范与标准化，往往更容易对后期发展造成较大影响（如加个参数，改 A 错 B）

接口标准做好了，换成 RPC 或其他协议，想必也不会困难到哪里去

题图：采用分层架构的某某系统，接口抽样说明

无论分布式数据库，还是数据库集群

自打这世界上有了关系型数据库之后，就从来没听说在高可用上缺乏过解决方案，对于某些非热点（双 11，大促之类）应用或服务，分不分布式，有那么重要吗？

比起运维成本与聚合数据时，应用付出的额外开销，采用数据库集群来满足，可能是一个非常不错的选择

杀鸡不用牛刀，不仅想起了当年的 EJB

回忆起十几年前，那个 EJB 大肆盛行的年代，我见过 40+人的团队，使用 EJB 开发电商系统，同时我也见过 3 个人的团队，使用 EJB 开发 OA 系统的……

面向成果，还是面向简历？

上半年接触到的一个名词 “简历驱动开发”（Resume Driven Development），在很多技术方案讨论中，恰恰融入了很多这样的因素，虽然本身并不是什么坏事，不过还是需要兼顾下 “系统利益获得者（使用方、业务方或运维成本）”

名词解释如下：

选择是否使用一项技术或者架构的标准是是否有利于自己的职业发展，而不是有利于客户/用户；

选择是否使用一项技术或者架构的标准是是否时髦而不是是否符合业务场景；

以技术的名义创造各种 NB 头衔（Job Title）；

记得有一次面试，我问面试者：

我：你们用 Docker 吗？

面试者：用啊

我：你们用 Docker 的目的是什么？

面试者：（……略去很多内容，这位小伙伴说了很多 Docker 带来的好处……）

我：嗯，你们有多少台服务器啊？

面试者：2 台

我：……2 台？为什么不选择 Master/Slave，而选择 Docker 呢？

面试者：节约资源呀，况且现在不是很流行吗？不用就要落伍啦，找不着工作啦

有些系统考虑未来毫无必要

每个系统都是有生命周期的，未来会发展成什么样？将一个在其生命周期内不可能产生高并发场景的系统设计成高并发架构，这种行为就是耍流氓

你那么断定吗？万一他哪天有了这样的场景呢？我只是说万一，那推倒重构的成本你过算吗？

当然没算过，不过可以预料的是，由于过度设计而导致的额外支出成本（如排障时间、人员离职及技术 BUG 等）一定比重构成本来的大，何况在大部分情况下，选择重构，多数是由于依赖系统的业务有了发展，我们才会痛下决心去重构，要不然为什么要去操这份心呢？

结束语

虽然从某种角度来说，分层架构与微服务并不属于同一级别，乃至同一层级的话题，但在实际工作场景中，往往会成为初期选择的争论点之一

记得在 SOLID 原则中提到

当我们不确定哪种架构更合适的时候，分层架构将是一个很好的起点

故事讲到这里应该结束了，也许，这样的故事每天都在发生，有可能这次是 A 君 “赢了” ，下次是 B 君 “胜了”，可作为系统设计者，是否更应多从系统的受益方（也许是业务，也许是 IT 的其他岗位）来思考呢？

也许哪一天，“合理的选择” 将不再充满争议……

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/kGQoNNsJeKZ5d-hYSobzpA