問題的產生

服務的錯亂

相信做app后臺的朋友們都會遇見這樣的情況，在不斷的版本迭代中，整個工程項目的代碼特別的臃腫，而且包含著錯綜復雜的調用，比如粉絲模塊依賴于用戶信息的獲取，直播模塊依賴用戶的獲取，往往在版本的更新迭代中，我們不能整理好相互之間的調用，再加上互聯網項目對迭代速度極致般的追求，導致代碼的維護變得越來越困難。

版本依賴

在app的更新迭代中，可能會因為需要版本兼容的關系出現一些傳統(tǒng)web不會遇到的關系，比如我們要修改一些用戶信息，那么我們可能要思考是否會影響到關聯的模塊，是否會影響到上一個版本的服務。

舉個例子：

例如我有個a服務，從1.0到2.0版本的時候可能就多了點參數返回，這時候我核心服務加上多的參數就夠了，能保證api層面的兼容，代碼層面也不會影響1.0的服務。
但是這時候我有個b服務，從1.0到2.0的話類型都變了，但是這個服務里的service層代碼有一半相同代碼，還有一半不同的代碼，而這段代碼是屬于那種參數賦值類型（諸如此類沒有必要提出來成公共代碼的）。
那這時候我就要為b實現1.0和2.0兩個版本的代碼，然而又很多重復之處，那如果到3.0或者4.0我這個代碼就很臃腫了，實現看起來就很不優(yōu)雅了

問題的原因

上述的描述中，我們大概發(fā)現一些問題產生的原因，就是我們在每次的迭代中，沒有規(guī)劃好我們的每個服務。導致我們的服務直接的依賴特別錯綜復雜，才會出現上述的問題。

如何解決

初期設計

在業(yè)務編排上做出一個模型的抽象，吧現有業(yè)務抽象做到最大化，做好基層架構。

業(yè)務編排

首先普及一下服務類型的概念

服務分為原子服務、組合服務、流程服務
流程服務指的是整合跨各個業(yè)務領域的組合 服務或原子服務 的一個特殊的組合服務
如果是屬于跨部門，跨公司一些服務的話（提現在流程性方面的），可以劃分到服務編排這里

例如一個充值服務中，分成校驗模塊、加錢模塊、日志模塊等，那么加錢這個模塊是不能再往下細分的，這時候我們的加錢模塊就可以稱之為一個原子服務。而這個充值服務是對因為一個業(yè)務流程而對若干個原子服務的組合，但是這個充值服務更偏于一個整個模塊的業(yè)務，所以充值服務可以稱為流程服務

其實流程服務是一種特殊的組合服務，流程服務也可以是一個原子服務的對接。
而為什么要有組合服務的出現呢，因為某些原子服務的組合出來之后，可以針對更多的業(yè)務流程所公用，所以這時候比流程服務小一級的組合型的服務，就叫做組合服務。

流程服務可以對任何服務進行流程化，主要是一些業(yè)務流程易變的，可以通過業(yè)務編排語言來進行靈活性的編排。從我們的產品編碼開始到之后的版本迭代甚至重構中，一定要把服務抽象(分離)化做好。

如何解決版本迭代帶來的問題

• 首先，我們先把公共的邏輯可以抽象出來下移一層，沒必要非得在api層去實現。
• 其次，服務調用方需要有一個字段指明版本號
• 吧服務層變成多個層級，例如接入層和邏輯層等等，接入層實現版本控制，邏輯層去實現重復邏輯
• 在協(xié)議里指明版本，然后服務端把不同的版本調用路由到不同的handler里，可以理解為，不同版本的業(yè)務service層，會有多個版本的service實現
• 對于某些特定需求的大版本迭代，需要制定可以兼容的最低版本。
• 對于新增的版本服務，采用邏輯增加的方式，保證服務的兼容性。