如何避免程式設計師和產品經理打架？“微服務”或將成終極解決方案
程式設計師與產品經理打架，早已稱不上網際網路圈的新聞。懷揣改變世界的遠大抱負，卻要每天和多變刁鑽的需求戰鬥，這是許多程式設計師的“生存困境”。那麼除了板磚和拼死不從，程式設計師就沒有別的對付變態需求的辦法嗎?
持續更新是產品常態
不否認存在過於異想天開或需求不清的產品經理，諸如要求“App隨手機殼變色”，此時程式設計師只想掄起板磚，拍死產品經理。然而在這個網際網路成為基礎設施的數字經濟時代，需求的變化是常態，不論哪個行業，不管是為滿足客戶或是出於競爭壓力，都會有需求的變動挑戰程式。很多時候，程式設計師即便把產品經理打到生活不能自理，也無助於解決企業發展的問題。
根據IDC《數字經濟創新引領——2018中國企業數字化發展報告》，數字化創新需要打造的多項能力與變化有關，譬如：
敏捷能力：企業在不斷變化、不可預測的經營環境中快速反應並給予恰當應對措施的能力。
數字化產品與服務：通過不斷迭代、實驗和測試的方式開發新產品與服務，並實現頻繁乃至連續更新，不斷提供客戶價值的能力。
鑑於當前市場競爭的激烈程度，我們甚至可以推論，企業所允許的迭代頻率，決定了這個企業成長的下限。在這種情況下，程式設計師的工作變得更繁忙、更瑣碎也是必然。
微服務的曙光與陰影
解決這種矛盾，必須把目光投向一直在迭代中發展的網際網路公司，新的答案將是“微服務架構”。以不追逐風口穩健發展的網易為例，網易考拉採用微服務架構之後，每天的釋出次數從2次做到了1000次，500倍的提升，可謂從步槍到大炮。
所謂微服務架構，就是將應用服務按功能拆分成一組相互協作的服務，每個服務負責一組特定、相關的功能，可以獨立開發、部署。用網易副總裁、網易杭州研究院執行院長汪源的類比解釋，就是把系統劃分成多個非常小的模組，而且這些模組都可以通過一套標準的服務介面進行溝通，從而持續發展——類似人類社會，基於人這個最小單位，設計了標準的語言、文字、貨幣、法律，發展形成了發達的文明。
微服務對整體問題的分解，為迭代帶來了好處——區域性的技術選擇、變更不會影響整個系統，而且不同模組的開發可以同時進行。然而，整個系統的完善程度，也受限於微服務“分”與“合”的各項標準，這正如文字、法律等標準的成熟度決定一個文明的高度。
微服務的“標準”至少需要解決如下問題：微服務之間的呼叫和通訊、服務之間的發現、服務呼叫鏈的跟蹤和質量問題、微服務的測試因依賴關係變得複雜、跨服務的更改。
當然，還有分割槽的資料庫體系和分散式事務這樣的問題。
立體化的微服務方案緩解矛盾
解決上述問題的，有不少微服務框架。在微服務技術迅速普及的今天，Spring Cloud、Dubbo等開源微服務開發框架在某種程度上成為了微服務的代名詞。知乎上有不少相關的討論。
微服務框架並不能解決所有的問題。比如Dubbo在服務治理方面很優秀，但功能不如Spring Cloud完善;Spring Cloud雖是一個體系化的微服務解決方案，卻也沒有覆蓋整個應用生命週期，比如對微服務測試就鞭長莫及。
網易考拉使用的工具，是網易雲在2018網易雲創大會上釋出的“輕舟”微服務解決方案。汪源表示，輕舟微服務基於微服務這個基本單元，構建了多維度完整的解決方案，讓架構可以像人類社會一樣持續發展。
根據網易雲官方資料顯示，輕舟微服務包括微服務框架、API閘道器、DevOps、容器服務、AIOps和測試平臺等模組，是一套複雜的解決方案，但是對使用者來說是功能完整、易接入、易運維——因為該平臺相容開源微服務框架，並整合了網易微服務架構實踐的
各種工具，藉助智慧化、自動化的能力，能夠快速分析整個服務鏈路，技術發現和解決問題，讓微服務順暢執行。
相信這個立體化的微服務解決方案，能夠啟發企業建設新的開發流程，使企業的數字化產品與服務能夠更快、更好地迭代，程式設計師也有更多的時間去和產品經理進行有效的溝通，讓雙方的矛盾得以緩和，而企業業務目標的完成也不會受到影響。