为什么要将应用微服务化？

其实在十多年前，“架构师”并不是一个需求很大的职业，一来那时还没有“全民 App”级别的应用，除了三大门户网站以外，其他的网上应用业务压力并不大;二来也没有现如今这么丰富的技术选型，几乎清一色的 PHP(坊间一直流传着 PHP 是世界上最好的语言这个说法，我 08 年左右写过一年 PHP，那是我人生最黑暗的一年)。因此呢对所谓“架构师?”的需求并不是很大，那些年的高可用架构大体上就是这个样子的:

在上面的反向代理集群之下，是众多 Web 服务器构成的高可用集群不过这些服务器中部署的应用却是千篇一律，什么意思呢?大家看过火影忍者吧，里面主人公经常用的一招叫“多重影分身之术”,将一个自己的本尊复制为成千，上万个本尊。这里的服务器集群是-个道理，将一个巨无霸的单体应用复制成 N 个单体应用，组成一个分布式的服务集群。

传统架构之殇

随着互联网行业的飞速发展，个人的衣食住行几乎全依赖各种 APP 来满足。每天早上起来刷刷淘宝，地铁，上用视频 app 看个短句，- -天微信不离手，睡前刷个抖音- -不小心就刷到了后半夜，这些现象级全民应用层出不穷，所承接的用户访问量远飞上古时期的门户网站所能比拟的。在这种用户量级下还要能够满足不断变化的用户请求，就像给飞行中的飞机换引擎，传统的架构模式已经完全不能满足业务发展的节奏。

我们来举几个“单体应用”中经常被人诟病的几个问题:

数据访问杂乱

同一个 war 包内，在数据访问层面没有划分领域模型，比如说我们有 User、Product 和 Order 三张表， 对于不同的 Service 来说， 都通过直接访问数据库的方式来获取数据。这种做法有几个显而易见的缺点:

1)数据模型变更

拿 Order 表来说，如果某一天我的 Data Model 发生了重大变更，比如说引入了“子订单”的概念，原先的数据模型不能再很好地支持业务必须重构 Orderi 订单表，与此同时，还要兼容老的订单结构。这种情况下你能贸然改动数据模型吗?恐怕不行，原因就是这个 Order 表被这个系统中的各个服务引用到了，你的改动可能会破坏其他服务的功能。

再举个例子，Product 表 以前存放的是单个的商品记录，数据模型非常简单，后面引入了 SKU 的概念，这就要对数据模型做重大改动,同时还可能影响到库存模块(以往库存落在 Product 级别，现在要落地到 SKU 级别)。

以上都是我做电商业务中遇到的实际场景，对于传统的应用结构来说，一丁点数据结构的改变都会引起很大的影响。如果数据模型的变动是必须的，那我们如何解决这种情况呢?很简单，通过微服务架构在各个服务之间做好隔离，将 Data Model 的影响带来的业务复杂度隔离在当前微服务中，划分好领域模型，上' 下游服务只要对接微服务的接口就可以，领域模型驱动不用依赖底层数据结构的变更。

2) 底层组件变更

假如现在我要对 Product 表的数据访问规则做一个变更，比如引入 MyCat 分库分表，或者对热点数据的访问加上缓存读写的步骤。那么意味着.上下游所有访问 Product 表的业务，都需要连带着做同样的改动。

再说个更极端的例子，以前我们使用的是 Oracle,这家伙老贵了，领导层想要换成 MySQL,即便我们没有存储过程的牵绊，那么这个变更也是极其巨大的，可谓牵一发而动全身。

理论，上来说，我们应该尽可能对业务层屏蔽底层组件的变更，在传统的分布式应用中非常难以办到，但是在微服务架构下却没有那么困难，因为微服务间的访问依赖 API 接口+业务模型，我们只要在当前微服务中把这种底层组件的变更处理好，对上下游其他服务来讲这个变更其实是无感知的，因为在微服务接口暴露出的业务模型并不会有什么变化。

代码复用带来的维护成本

一整个应用的代码掺杂在一块，少不了各种“借鉴”，咱来细数下这里面的坑:

1)码农的傲娇-rewrite code

作为一个骄傲的码农，看别人写的代码都跟屎一样，只有自己出品的才是最好的。路见不平重构一番，重构不了的干脆重新写个功能上一模一样但是代码结构上更“优雅”的接口出来，随着时间的推移，这深藏于码农血液里的“rewrite code”基因，终究会把一个代码库编程一座屎山。

2)小改动没什么大不了

“我就改了个 if 条件啊，谁知道你们也用了这个方法，这方法我当初就写给自己用的啊!”

码农之间的撕逼没有那么轰轰烈烈，反正最后归根结底就是-改出 bug 来了。上面那个情景在传统架构的系统里很常见，当你的业务需要添加一个新功能，瞄了几眼发现，咦?我去年写的这个方法改一下正好能用，随手改了个 if 条件。谁曾料想，隔壁组的程序媛妹子没打招呼也用了这个方法，被你这么一改，把别人的服务搞挂了，又不好意思跟人妹子撕逼，只好自己背了个生产事故的锅。

时不我待！糙快猛才是生产力

不知道大伙有没有经历过互联网公司的业务节奏，拥抱变化不是白叫的，研发团队沉浸在 996 的福报中不能自拔。就像前面说的，为了支持不断变化的新业务，开发团队对系统的改造就像给飞行中飞机换引擎，既要让飞机飞，又要保证完成任务，还得要快。因此我们提出了“糙快猛”的开发模式，它是继瀑布模型、敏捷模型等等软件工程理论之后的具有中国特色的互联网研发模式。

面对一个屎山- -般的单 war 包应用，产品的发布节奏往往是以月甚至年来计，-个变更从评估到上线，拖个- -年半载是很常见的事情这种节奏对于互联网公司来说，倒闭 100 次都够了。

小步快跑

互联网产品的迭代依靠小步快跑，尽快上线，尽快验证业务模式,有问题立即调整，-切都是“快字当头”。对于传统应用来说，发布节奏只能划归到一个千年等-回的发布窗口，再小的变更都得耗上很长的时间，可能每次发布都要经历很耗时的全链路回归测试。对微服务架构来说完全不存在这个问题，每个微服务模块由于职责边界足够清晰，规模可控便于快速变更和测试，完全可以让团队自己制定发布窗口，即便是上线前的回归测试也只局限在当前服务模块

回滚

回滚对于传统的单 war 包分布式系统来说是个噩梦，好不容易等到了发布窗口，各个团队牟足了劲把所有变更都发布了出去，结果因为其中某个小改动引发的问题，导致全部回滚。又要苦苦等待下一个发布窗口。

在微服务架构中，回滚只局限在某个微服务的范围内，只要把出问题的应用回滚就好了，不会影响上下游其他应用的发布节奏。

技术前沿拓展

前端开发，你的认知不能仅局限于技术内，需要发散思维了解技术圈的前沿知识。细心的人会发现，开发内部工具的过程中，大量的页面、场景、组件等在不断重复，这种重复造轮子的工作，浪费工程师的大量时间。

介绍一款程序员都应该知道的软件JNPF快速开发平台，很多人都尝试用过它，它是功能的集大成者，任何信息化系统都可以基于它开发出来。

这是一个基于 Java Boot/.Net Core 构建的简单、跨平台快速开发框架。前后端封装了上千个常用类，方便扩展；集成了代码生成器，支持前后端业务代码生成，实现快速开发，提升工作效率；框架集成了表单、报表、图表、大屏等各种常用的 Demo 方便直接使用；后端框架支持 Vue2、Vue3。如果你有闲暇时间，可以做个知识拓展。

看完本文如果觉得有用，记得点个赞支持，收藏起来说不定哪天就用上啦～