有關「服務定義」與研發如何結合的想法

這幾天我看了幾篇有關貴公眾號發布的「服務定義」有關文章，雖然我是一名程序員，我不是專門做IT服務或者運維的人員，但是我想對這個理念怎麼跟開發結合談談自己的想法。

首先，我能理解到的是，」服務定義」是細粒度分解後再重組的一種服務交付方式，目標是加速企業數字化轉型，適應高速迭代的業務發展節奏。

程序員日常交付的雖然不是服務，但是交付的會是產品或者是應用。

「服務定義」在內部將用戶需求進行分解，然後對外分發，這個過程讓我聯想到容器。

容器先是弄成鏡像，然後可以到處分發，它不用管開發環境，不用管測試環境，也不用關心用戶的生產環境。

不同的是，容器能做得很輕，就是不知道「服務定義」交付的服務能不能也做到很輕。

容器能夠實現自動化的運維，把代碼、測試和運維的環節都打通，這個似乎也同「服務定義」追求實現的「連接」作用相一致。

另外，用容器打包應用交付給用戶，也讓應用上雲方便多了。在這方面，「服務定義」估計目前還達不到這樣的服務便捷交付，但是我倒是蠻期待的。

容器之間也是有通信的，一般用HTTP的API。「服務定義」裡面各種服務是怎麼通信的，這個我倒是還沒看到相關的介紹，希望今後能有一些這方面的補充。

其次，「服務定義」讓我看到了微服務的影子。微服務互相之間都是獨立的，能夠自由伸縮，但是前提是，獨立的服務都會明確自己的邊界。從目前公開的資料看，「服務定義」中的服務沒有說明它所生成的服務是不是擁有邊界。我覺得有這樣的邊界是最好的，因為如果細粒度化的程度更高後，服務之間是否有重疊是很難控制的，另外因為服務自由度也沒有明確，這種重疊我感覺是必然會有的。這時候你再沒邊界的話，亂是必然的。

微服務支持不同技術棧，就像「服務定義」鼓勵跨產品、技術等的融合。好像看文章，「服務定義」也允許營銷資源的嵌入，這個會是怎麼結合，我很感興趣，什麼時候也能把研發也嵌入進去更好。

另外我關心的一點是，需要看到的是如果用戶之前習慣了從前頻繁溝通、項目化交付的服務交付模式，你們會怎麼向他們推送「服務定義」？因為這些用戶通常不會一下子做很徹底的改變，他們也更在乎可能出現的額外成本投入和不可知的風險。所以這時只有一條路，那就是新的服務用「服務定義」，舊的服務還是跟以前一樣，然後繼續保持更新，有新需求就去滿足新需求。

還有就是，「服務定義」這麼交付服務，跟以前相比，能否帶給用戶更多的安全感。目前「服務定義」似乎還沒有就安全性做出有關論述。我的建議是參考容器那種隔離的做法，交付不同服務時，要麼項目的團隊成員是隔離的，要麼服務本身使用的各種資源是隔離的，並且也為哪種用戶可以獲得哪種「服務定義」提供的服務做一個許可權的規定，然後去執行。

最後，「服務定義」在一個公司內部究竟應該怎麼運作，不知道今後會不會有一個教程出來？比如說你的發起方是誰，你的需求是什麼，能夠給誰提供服務，能夠怎麼服務都能解釋清楚。還有就是「服務定義」是萬能的么？是不是說所有的服務供應商都能使用，這些都得去驗證吧？

因為只看了三篇文章，而且每篇看的都不是很深，所以只是想起什麼就寫什麼，其中一些觀點和邏輯可能還不是很完善，望見諒。

推薦閱讀：