# 后臺與服務篇
### PHP？最好的語言
### RESTful與服務化
### 設計RESTful API
> REST從資源的角度來觀察整個網絡，分布在各處的資源由URI確定，而客戶端的應用通過URI來獲取資源的表征。獲得這些表征致使這些應用程序轉變了其狀態。隨著不斷獲取資源的表征，客戶端應用不斷地在轉變著其狀態，所謂表征狀態轉移。
因為我們需要的是一個Machine到Machine溝通的平臺，需要設計一個API。而設計一個API來說，RESTful是很不錯的一種選擇，也是主流的選擇。而設計一個RESTful服務，的首要步驟便是設計資源模型。
### 資源
互聯網上的一切信息都可以看作是一種資源。
| HTTP Method | Operation Performed |
|-----|-----|
| GET | Get a resource (Read a resource) |
| POST | Create a resource |
| PUT | Update a resource |
| DELETE | Delete Resource |
設計RESTful API是一個有意思的話題。下面是一些常用的RESTful設計原則:
- 組件間交互的可伸縮性
- 接口的通用性
- 組件的獨立部署
- 通過中間組件來減少延遲、實施安全策略和封裝已有系統
判斷是否是 RESTful的約束條件
- 客戶端-服務器分離
- 無狀態
- 可緩存
- 多層系統
- 統一接口
- 隨需代碼（可選）
### 微服務
### 微內核
這只是由微服務與傳統架構之間對比而引發的一個思考，讓我引一些資料來當參考吧.
> 單內核：也稱為宏內核。將內核從整體上作為一個大過程實現，并同時運行在一個單獨的地址空間。所有的內核服務都在一個地址空間運行，相互之間直接調用函數，簡單高效。微內核：功能被劃分成獨立的過程，過程間通過IPC進行通信。模塊化程度高，一個服務失效不會影響另外一個服務。Linux是一個單內核結構，同時又吸收了微內核的優點：模塊化設計，支持動態裝載內核模塊。Linux還避免了微內核設計上的缺陷，讓一切都運行在內核態，直接調用函數，無需消息傳遞。
對就的微內核便是:
> 微內核――在微內核中，大部分內核都作為單獨的進程在特權狀態下運行，他們通過消息傳遞進行通訊。在典型情況下，每個概念模塊都有一個進程。因此，假如在設計中有一個系統調用模塊，那么就必然有一個相應的進程來接收系統調用，并和能夠執行系統調用的其他進程（或模塊）通訊以完成所需任務。
如果讀過《操作系統原理》及其相關書籍的人應該很了解這些，對就的我們就可以一目了然地解決我們當前是的微服務的問題。
### 微服務
文章的來源是James Lewis與Martin Fowler寫的[Microservices](http://martinfowler.com/articles/microservices.html)。對就于上面的
- monolithic kernel
- microkernel
與文中的
- monolithic services
- microservices
我們還是將其翻譯成`微服務`與`宏服務`。
引起原文中對于微服務的解釋:
> 簡短地說，微服務架構風格是一種使用一套小服務來開發單個應用的方式途徑，每個服務運行在自己的進程中，通過輕量的通訊機制聯系，經常是基于HTTP資源API，這些服務基于業務能力構建，能夠通過自動化部署方式獨立部署，這些服務自己有一些小型集中化管理，可以是使用不同的編程語言編寫，正如不同的數據存儲技術一樣。
原文是:
> In short, the microservice architectural style [1](http://repractise.phodal.com/img/a-arch/blog-mobile.jpg) is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare mininum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
而關于微服務的提出是早在2011年的5月份
> The term “microservice” was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring.
### 微服務思考
簡單地與微內核作一些對比。微內核，**微內核部分經常只但是是個消息轉發站**，而微服務從某種意義上也是如此，他們都有著下面的優點。
- 有助于實現模塊間的隔離
- 在不影響系統其他部分的情況下，用更高效的實現代替現有文檔系統模塊的工作將會更加容易。
對于微服務來說
- 每個服務本身都是很簡單的
- 對于每個服務，我們可以選擇最好和最合適的工具來開發
- 系統本質上是松耦合的
- 不同的團隊可以工作在不同的服務中
- 可以持續發布，而其他部分還是穩定的
從某種意義上來說微服務更適合于大型企業架構，而不是一般的應用，對于一般的應用來說他們的都在同一臺主機上。無力于支付更多的系統開銷，于是如**微服務不是免費的午餐**一文所說
- 微服務帶來很多的開銷操作
- 大量的DevOps技能要求
- 隱式接口
- 重復努力
- 分布式系統的復雜性
- 異步性是困難的！
- 可測試性挑戰
因而不得不再后面補充一些所知的額外的東西。
### 微服務與持續集成
針對于同樣的話題，開始了解其中的一些問題。當敏捷的思想貫穿于開發過程時，我們不得不面對持續集成與發布這樣的問題。我們確實可以在不同的服務下工作，然而當我們需要修改API時，就對我們的集成帶來很多的問題。我們需要同時修改兩個API！我們也需要同時部署他們！
#### 微服務與測試
相比較的來說，這也是另外的一個挑戰。測試對于項目開發來說是不可缺少的，而當我們的服務一個個隔離的時候，我們的測試不得不去mock一個又一個的服務。在有些時候修復這些測試可能比添加這個功能花費的時間還多。
不過他更適合那些喜歡不同技術棧的程序員。
### 參考
[Microservices - Not A Free Lunch!](http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html)
[Microservices](http://martinfowler.com/articles/microservices.html)
