1樓：swxlion
帶版本號是一種方法，更常見的是更換接入網域名稱。
比如舊版訪問的是 http://api.example.com，新版就改為 http://apiv1.example.com。
第三種就是雙介面。新版服務為了相容舊版，同時提供舊版的介面。這種方式比帶版本號更常見一點。但帶來的是雙倍介面，雙倍工作量。
但是，以上我們都不使用！！！
我們的路子比較野，因為還存在第四種方式！！！
灰度介面！！！
灰度介面最核心的需求是：使用無IDL的RPC框架！！！
比如 FPNN框架 （FPNN技術生態沒有全部開源，目前只開源了RPC框架、DBProxy、TableCache和SDK。很多核心服務和元件沒有開源。比如RTM（全球資料實時傳輸系統）更是作為商業服務進行銷售。
這點和Dubbo等是完全不同的）。
很多人可能認為，RPC就必須有IDL，無論是grpc、thrift、brpc等。沒有idl還算什麼RPC？
可是，就好比ProtoBuf，一旦全部使用optinal（這是可是官方推薦方式，require不再推薦哦～），那本質上就是乙個idlless的RPC協議，本質上除了更麻煩點外，和無IDL的RPC其實已經沒啥區別了。
那好，到了這一步，所有的引數，對協議而言，都是optional的，只有業務才知道，那些是require，那些是optional。而且，特別重要的是，只有業務知道，對於不同版本，那些是require，那些是optional，那些是ignore！！！
這是灰度介面實現的大前提。
當然，你也可以和我槓，你乙個大的struct裡面包含所有可能用到的引數。也行，你不覺得維護麻煩，RPC通訊包不嫌大，序列化/反序列化不嫌效率低就行。
然後，無論是伺服器內部，還是客戶端有多個版本，無所謂，要上AB版上AB版，嫌麻煩，或者AB Test已經完成，只是相容的話，直接上灰度介面。
這是第四條路，我們的辦法。
微服務架構是什麼？
山間霧 傳統服務是乙個大盒子把需要的功能都放進去，體積比較臃腫，而且這些功能互相沒有太大關聯，需要自己進行拼裝和維護 微服務是把除基礎功能外的所有功能都放在外面，並且這些功能都形成統一的元件化，開發者可以自定義配置，高效標準規範 在巨集觀方面更好維護和管理，微觀方面輕巧切易於維護。 已登出 微服務是...
電商，Spring Cloud架構，微服務之間耦合過多的問題如何解決？
倚天碼農 你講了了兩個問題。乙個是高度耦合 程式架構和設計 另乙個是http的呼叫效率。這兩個問題的解決方案一般情況下是互相矛盾的。要想解決高度耦合，就需要優雅的設計，但一般效率都不高。要想提高效率，就要使用一些特殊的設計和手段，這必然使程式設計很難看。我們先來看高度耦合 程式架構和設計 模組拆分之...
集中式架構和分布式架構哪種更好？
父母在尚有來路 為什麼一定要分出來哪個更好？集中式和分布式架構各有千秋，關於誰更優質，也一直爭論不休。但是其實是可以和平共處的，互相融合才是未來發展的趨勢。之前在其他地方看到乙個辯論賽，IPS架構之爭辯論賽。辯論雙方都說的很有道理，沒有絕對的好，只有相對的合適。 阿群吖 應該是各有利弊吧，不能簡單說...