update if

ch5-web/ch5-08-interface-and-web.md

@@ -6,9 +6,17 @@
 2. 平台部门的老用户系统年久失修(怎么都是年久失修，摔！)，现在已经没有人维护了，真是悲伤的故事。新系统上线没有考虑兼容老接口，但最后通牒已下，要求 N 个月之内迁移完毕。
 3. 公司的老消息队列人走茶凉，年久失修(汗)，新来的技术精英们没有考虑向前兼容，但最后通牒已下，要求半年之内迁移完毕。
 
-嗯，所以你看到了，我们的外部依赖总是为了自己爽而不断地做升级而不想做向前兼容，然后来给我们下最后通牒。如果我们的部门工作饱和，领导强势，那么有时候也可以倒逼依赖方来做兼容。但世事不一定如人愿望，即使我们的领导强势，读者朋友的领导也还是可能认怂的。
+嗯，所以你看到了，我们的外部依赖总是为了自己爽而不断地做升级，且不想做向前兼容，然后来给我们下最后通牒。如果我们的部门工作饱和，领导强势，那么有时候也可以倒逼依赖方来做兼容。但世事不一定如人愿，即使我们的领导强势，读者朋友的领导也还是可能认怂的。
 
-我们可以思考一下怎么解决这个问题。
+我们可以思考一下怎么缓解这个问题。
+
+## 业务系统的发展过程
+
+互联网公司只要可以活过三年，工程方面面临的首要问题就是代码膨胀。系统的代码膨胀之后，可以将系统中与业务本身流程无关的部分做拆解和异步化。什么算是业务无关呢，比如一些统计、反作弊、营销发券、价格计算、用户状态更新等等需求。这些需求往往依赖于主流程的数据，但又只是挂在主流程上的旁支，自成体系。
+
+这时候我们就可以把这些旁支拆解出去，作为独立的系统来部署、开发以及维护。这些旁支流程的时延如若非常敏感，比如用户在界面上点了按钮，需要立刻返回(价格计算、支付)，那么需要与主流程系统进行 RPC 通信，并且在通信失败时，要将结果直接返回给用户。如果时延不敏感，比如抽奖系统，结果稍后公布的这种，或者非实时的统计类系统，那么就没有必要在主流程里为每一套系统做一套 RPC 流程。我们只要将下游需要的数据打包成一条消息，传入消息队列，之后的事情与主流程一概无关(当然，如果与用户的后续交互流程还是要做的)。
+
+通过拆解和异步化虽然解决了一部分问题，但并不能解决所有问题。
 
 ## 使用 interface 来做抽象