小編從事軟體開發十余年，咀嚼著JAVA的語法糖一路走來， 開發框架從EJB、Struts1 + EJB、Struts2+hibernate、Spring MVC + mybatis 到 Springboot； 軟體架構從構建本體應用，到基于webservice 的SOA，再到微服務， 框架越來越好用，開發越來越簡單，架構卻越來越復雜， 我近年來從事一個國內知名APP的構架、設計、開發作業，目前APP運行良好，兩年來注冊用戶達千萬，榷訓也有30萬，一個20人的團隊，平臺運營、運維壓力適當，還能即使回應客戶的需求，面對兩年來積累的大大小小40多個微服務，思之甚恐，如果不是一點點積累起來的，就我們團隊里4、5個研發工程師無論如何都無法完成的，常常在想像微服務這種復雜的體系化架構是否是中小型公司傳統應用軟體構架的優選？ 微服務架構的最佳實踐是什么？
判斷微服務架構是否合適？ 首先，咱們從如下幾個典型優點進行分析：
- 松耦合，可以快速回應用戶需求，而不影響現有服務，這里有就有個問題，如果是全新開發的系統，沒有線上系統，自然也不會影響線上服務，軟體建設之初，就構建大量松耦合的微服務專案，如果團隊人員配備少，一個人動輒維護幾個甚至十幾個專案是一件很折磨人的事情，
- 開發簡單，一個人可以專注一件事，如果組織和團隊人員有保證的話，這是一個優點，可在一個中小型的軟體公司里，永遠都是一個人干很多事，拆散的微服務是個噩夢，
- 利于沉淀公共組件，微服務固然可以達到這個目的，可是這不是唯一途徑，在專案建設初期，通過公共模塊開發，更有利于團隊快速迭代，
- 允許跨語言開發，而對于一般的中小型軟體公司，基本要求就是統一語言，降低學習成本，提升效率，跨語言開發基本不存在，
其次，而微服務帶來的問題不容小視：
- 部署運維 微服務開發模式下產生的大量程式包的版本管理、部署運維都會導致作業量大大增加，
- 認證、授權、成熟的門戶網關系統， 微服務的統一鑒權不建議采用傳統的單點登錄，而是通過精心設計的網關系統實作服務的代理，
- 分布式架構具有很強的高可用性，但是隨之而來的分布式事務等問題更是無法回避的硬傷，
總之， 微服務真的不一定會提升請求的回應速度，倒是會因為各種網路呼叫而降低性能，總之，如果一個簡單的集群和會話共享就能解決的問題，大動干戈地上微服務，處理與團隊技術實力不符的分布式事務、服務阻斷、服務跟蹤和各種服務拆分不合理帶來的問題是非常不明智的，所以， 要構建一個微服務架構的系統，有如下幾點建議考慮：
- 需要有充足的人員和組織保障，軟體架構一定要與組織分工相匹配，否則，研發周期無法保證，
- 需要有成熟的配套設施，包括容器環境、鑒權網關等，不要指望開源的各種版本的Cloud 提供完善的技術方案，
- 非常清晰的服務迭代路線， 選擇微服務就是一個最大的價值就是分片迭代升級，而不會影響全域，從而提升產品迭代升級的周期，
- 團隊里有業務專家，有非常專業的業務抽象能力，避免面向資料庫的微服務開發，
- 沒想明白如何拆分服務，那就暫時不拆，等考慮清楚了再重構，
經常和朋友討論當下流行的框架，說Spirng Cloud如何如何流行，某些大型廠商都在基于它做開源產品，社區常見某些大型云服務廠商推出的Spring cloud系列開源產品，我在想他們自己主流產品會采用這樣的架構么？ 他們的動機是在促進軟體行業技術進步，為開源做貢獻？ 還是一個市場戰略操作，用流行的架構包裝他們的云產品，借助他們的品牌和技術實力達到行業技術壟斷或云產品市場營銷的目的呢？
最后，祝愿大家不要做框架的弄潮兒，努力爭取做框架的主人，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/237218.html
標籤：其他
上一篇：【粉絲投稿】一個秋招幫助自己成功上岸，拿到阿里和騰訊的入職offer，分享自己的面試經驗希望幫助到大家！
下一篇：資料湖初識