如何在分层架构与微服务之间做出合理的选择？
题图：设计理论的完善
最近似乎所有的电台里都在为国庆长假倒数计时，身边的小伙伴们好像也提前进入了庆欢状态，连我也提前一周打点好了潜水装备，耐心等待那黄金一刻的到来
按照惯例，每年十一黄金周是公司启动下一年战略规划的触发点，对于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的其他岗位）来思考呢？
也许哪一天，“合理的选择” 将不再充满争议……
近期发表文章：
扫描二维码或手动搜索微信公众号【吃草的罗汉】
欢迎转载，带上以下二维码即可
点击“阅读原文”，所有【吃草的罗汉】近期的文章汇总
↓↓↓