1.項目架構演變中的思考：
爲何要使用微服務架構:
單一架構模式在項目初期的時候開發,測試,部署方便,但是隨着項目逐步開發,項目工程會很大,最終項目的耦合性會非常高，維護和擴展會變得非常複雜。
- 不適合敏捷開發，任何模塊的漏洞修復都需要開發人員去梳理調用關係，修改後對其他模塊的影響很難估量；
- 項目模塊越來越大對程序的執行效率影響非常大，新人員接手非常痛苦；
- 任意模塊的漏洞對項目整體的穩定性和安全性的威脅特別大；
- 因爲模塊之間的依賴關係，需要技術升級會帶來非常繁重的兼容性工作。
使用微服務的優點：
- 服務的技術選型範圍非常寬泛，可以自由選擇最爲熟悉的語言和技術來實現；
- 服務是獨立的可以獨立開發測試，獨立部署，靈活的切換，具有非常強的容錯性；
- 服務單獨可以分佈式部署和負載均衡，提高服務的高可用性。
微服務的缺點:
- 同一物理服務器中的不同服務互相調用也要使用相應的協議調用，不會像單體應用一樣直接調用；
- 多數據庫中的事務操作非常麻煩，容易出錯；
- 微服務的測試工作比較麻煩，這個要因不同的語言和不同的微服務解決方案而論；
- 微服務在實踐中一般部署在不止一臺服務器上一般需要持續集成(CI/DI)工具。
綜上所述如果你是團隊架構師微服務會成爲你架構生涯中必須面對的選擇，當然不能一概而論，就算是當前有很多公司使用單體應用依舊能很好的應對公司業務。
2.微服務和rpc的關係
文章一開始我們本身是本着rpc去的但是我覺得來龍去脈必須瞭解下
微服務和rpc其實不是一個完全相等的東西。微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。
所以微服務是一種架構模式或者思想。在實現形式上如果我們把開發工作中司空見慣的restfull api按照單一應用劃分也可以稱得上是微服務。當然在微服務的解決方案中有使用restfull的方式實現的。
rpc的意思是遠程過程調用。他是一種微服務的調用方式。其實他要達到的目的和我們發送一個請求調用restfull接口一樣的。但是rpc從傳輸性能以及服務的調用和發現上都要優於restfull，所以我們需要rpc。rpc使你調用微服務的感受就像調用本地一個函數、一個對象或一個代碼塊一樣（這個只有體驗後才能感受到），其實你調用的整個過程就是rpc相關的協議幫你做了。
3.微服務框架如何選擇
當前成熟的微服務框架使非常多的。比較著名的有gRpc，dubbo，thrift，brpc，tars等等。在我以往任職的公司裏有使用過thrift和grpc的經歷。
這麼多rpc框架如何選擇其實對於架構師來說是不小的難題。一般我們選擇技術解決方案的時候需要考慮一下幾點：
- 生態的成熟程度，就是你要用到的東西基本上都能找到相關的方案，這個非常重要
- 社區的成熟程度，再好的東西你一個人閉門造車也造不出好東西來，社區的成熟度決定了你遇到問題後有沒有人一起交流解決。
- 穩定性，是比較成熟和穩定的技術
- 易用性，易用對於團隊合作來說非常重要，人員能夠快速上手直接提高了生產力
綜合上邊所說其實thrift和gRpc都是不錯的選擇，畢竟經歷了那麼久的積累和迭代。
4.選擇tars的理由
今天要說的是tars，其實tars在騰訊內部有着大量的使用。
tars有着以下的優點：
- 提供界面化的服務治理工具，大家可以看文檔中對於tars web的介紹
- 支持的語言非常全面，支持go、php、java、c++、nodejs、等等
- 使用起來非常簡單，tars本身提供了比較完備的工具鏈，但是官方文檔比較混亂
- 本身性能非常高
- 對於對象的序列化即支持tars協議也支持google的protobuf