微服務規范

⑴ 餐廳服務員日常行為規范

酒店服務員日常行為規范及要求

一、儀容儀表
1 男員工

1.1 頭發：不可漂染；保持頭發清潔，無頭皮屑；頭發後不蓋領、側不遮耳；可使用發膠，但不可過於油膩或潮濕；
1.2 面容：清潔，不準留胡須且必須每天剃須；經常留意及修剪鼻毛，使其不外露；
1.3 手/指甲：保持潔凈，不可有吸煙留下的污漬；定期修剪指甲，長度僅能遮蓋指尖；不塗指甲油；
1.4 服裝：著公司規定的制服，且必須保持干凈、整潔；冷天時，所穿的保暖底衣需保持不露在制服外。

1.5 鞋：黑色皮鞋或布鞋，皮鞋擦拭光亮，無破損；球童所穿的運動鞋須保持潔凈。

1.6 襪：穿深色無鮮艷花紋的襪子，勤換洗，保持無異味

1.7 飾物：只可佩戴簡單、大眾款式的手錶；已婚人士還允許佩戴一枚戒指（廚房員工除外）

1.8 名牌：須端正地佩戴在最外面的制服左胸區域，並保持光亮無破損

2 女員工

2.1 頭發：不可漂染顏色艷麗的發色；保持頭發清潔，無頭皮屑；過肩長發必須束起，不佩帶色彩艷麗的飾物，發夾須為黑色或深色
2.2 面容：保持清潔，不油，不幹，無皮屑；
2.3 手、指甲：干凈，修剪整齊，不塗帶顏色的指甲油（餐廳服務員禁止塗指甲油）；
2.4 服裝：著公司規定的制服，且必須保持干凈、整潔；天冷時，所穿的保暖底衣需保持不露在制服外；
2.5 鞋：黑色皮鞋或布鞋；皮鞋擦拭光亮，無破損；球童所穿的運動鞋須保持干凈；
2.6 長襪：著肉色的襪子，必須無花紋，不可抽絲或是網狀的；
2.7 飾物：只可佩戴簡單款式的手錶及一串項鏈（項鏈不可露出制服外）；已婚人士還允許佩戴一枚戒指（廚房員工除外）
2.8 工號：須端正地佩戴在最外面的制服左胸區域，並保持光亮無破損
2.9 化妝：須化淡妝；化妝應在上班前完成；不使用假眼睫毛；前台員工應經常補妝，但不能當著客人的面（球童不要求化妝）；
二、儀態
1 站姿：
1.1 身體端正，精神飽滿；挺胸收腹，兩肩水平，眼睛平視，嘴微閉，面帶笑容。
1.2 在服務區域內，身體不得東側西歪，不得依*在傢具或牆壁上；雙臂自然下垂，不得*腰、不得將手插在衣袋中；手中不得玩弄物品；
2 坐姿：
2.1 身體端正，不要把椅子坐滿，也不可坐在邊沿上；見到客人應立即站起；
2.2 坐在椅子上不得前俯後仰，搖腳蹺腿或半躺半坐；不得趴在工作台上；
3 行態：
3.1 走路昂首挺胸、收腹，肩要平，身體要端正；
3.2 男士走路時不要扭腰，女士不要搖晃臀部；
3.3 行走時不可搖頭晃腦、吹口哨、吃零食、左顧右盼，手插在口袋內或打響指，不可邊走手上邊玩弄物品；
3.4 行走中不與他人拉手、勾肩、摟腰、搭背；
3.5 走路*右行，不走中間；在走廊等狹窄地帶不得兩人並行；
3.6 同向行走，如因工作需要必須超越客人或上級時，要禮貌致歉，說對不起；
3.7 與上級、賓客同行至門前時，應主動開門讓他們先行；
3.8 客人迎面走來時，要主動側身為客人讓路；
3.9 非緊急事件發生，禁止在工作場合奔跑、跳躍；
4 手姿：
4.1 為客人指引方向時，要手臂伸直，手指自然並攏，掌心向上，指向目標；同時眼睛要看著目標並兼顧對方是否看到指示的目標；
4.2 在介紹或指示方向時切忌用一隻手指或用筆等物品來指點；
4.3 談話時手勢不宜過多，幅度不宜過大；
4.4 遞東西給客人時應用雙手恭敬地奉上，絕不能漫不經心地一扔；從客人手中接東西也同樣必須使用雙手；
4.5切忌以手指或筆尖直接指向客人
5 點頭與鞠躬
5.1 當客人或上級走到面前時，應主動點頭問好，打招呼；點頭時目光要看著客人或上級面部；
5.2 當客人或上級離去時，需點頭或鞠躬示意，敬語道別
三、舉止
1 迎客走在前，送客走在後，客人通過時要讓路， 同行不搶道，不許在賓客中間穿過；
2 在賓客或上級面前禁止各種不文明的舉動，如：吸煙、吃零食、挖鼻孔、剔牙、掏耳朵、打飽嗝、打噴嚏、打哈欠、抓頭、搔癢、修指甲、伸懶腰等，即使在不得已的情況下也應盡量採取措施掩飾或迴避；
3 不得隨地吐痰，扔果皮、紙屑、煙頭或其它雜物；看到地上有雜物需立刻拾起；
4 保持工作場合的安靜，說話聲音要輕，不大聲喧嘩或高聲喊人、打鬧、吹口哨、唱小調；不準交頭接耳；
5 走路腳要輕，操作聲音要輕，拿放物品動作要輕；
6 在公共場合不得將任何物品夾於腋下；
7 不可當眾整理個人衣物，進行個人修飾；
8 在公共場合接聽電話時，不得將電話夾於耳下，必須用手握住話筒；接聽過程中需要查找資料時，可將話筒暫時輕放在桌面上；
9 不得在客人面前經常看錶；
10 正在工作或與他人交談時，如遇客人走近，應立即示意，表明自己已注意到他（她）的到來，不得無所表示，等客人先開口；
四、表情
在為客人服務時，面部表情要注意以下幾點：
1 微笑，是起碼應有的表情；
2 要熱情、親切、友好；
3 要坦然、輕松、自信；
4 要沉著穩重，不卑不亢
5 不要帶有厭煩、冷淡、僵硬 、憤怒、緊張的表情，也不要做鬼臉、吐舌、眨眼；
五、言談
1 語調應自然、清晰、柔和、親切、不裝腔作勢；音量、語速適中，語氣溫和；
2 禁止使用粗話及侮辱、蔑視性的語言；
3 說話要講藝術，多用敬語，禮貌用語；「請」字當頭、「謝」不離口，不當之舉要說「對不起」；
4 注意使用恰當的稱謂稱呼客人；
5 注意稱呼客人姓氏，未知姓氏之前，要稱呼「先生」或「女士」；
6 不得模仿客人的語言，語調和談話；
7 禁止以任何借口頂撞、諷刺、挖苦客人；
8 回答客人問題要簡潔、准確，不知道的問題不能直接說「不知道」，而應盡量向他人請教以答復客人；
9不講過分的玩笑；三人以上對話，要用相互都懂的語言，工作期間不得使用方言；
10 離開面對的客人，要說「請稍候」。如果離開時間較長，回來後要講「對不起，讓您久等了」，不可一言不發就開始服務
11 基本禮貌用語

A、 稱呼語：小姐、夫人、先生、女士

B、 歡迎語：歡迎光臨、歡迎光臨我們酒店

C、 問候語：您好、早上好、下午好、晚上好

D、 祝賀語：恭喜、節日快樂、新年快樂

E、 告別語：再見、晚安、明天見、祝您旅途愉快

F、 道歉語：對不起、請原諒、打擾您了

G、 應答語：是的、好的、我明白了、不要客氣、謝謝您的好意

H、 道謝語：謝謝、非常感謝

I、 征詢語：請問您有什麼事？我能為您做些什麼？您還有別的事情嗎？

J、 基本禮貌用語：您好、請、謝謝、對不起、再見

⑵ REST 是微服務中最好的架構嗎

REST (REpresentation State Transfer) 描述了一個架構樣式的網路系統，比如 web 應用程序。它首次出現在 2000 年 Roy Fielding 的博士論文中，他是 HTTP 規范的主要編寫者之一。REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。Web 應用程序最重要的 REST 原則是，客戶端和伺服器之間的交互在請求之間是無狀態的。從客戶端到伺服器的每個請求都必須包含理解請求所必需的信息。如果伺服器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態請求可以由任何可用伺服器回答，這十分適合雲計算之類的環境。客戶端可以緩存數據以改進性能。在伺服器端，應用程序狀態和功能可以分為各種資源。資源是一個有趣的概念實體，它向客戶端公開。資源的例子有:應用程序對象、資料庫記錄、演算法等等。每個資源都使用 URI (Universal Resource Identifier) 得到一個惟一的地址。所有資源都共享統一的界面，以便在客戶端和伺服器之間傳輸狀態。使用的是標準的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是應用程序狀態的引擎，資源表示通過超鏈接互聯。另一個重要的 REST 原則是分層系統，這表示組件無法了解它與之交互的中間層以外的組件。通過將系統知識限制在單個層，可以限制整個系統的復雜性，促進了底層的獨立性。當REST 架構的約束條件作為一個整體應用時，將生成一個可以擴展到大量客戶端的應用程序。它還降低了客戶端和伺服器之間的交互延遲。統一界面簡化了整個系統架構，改進了子系統之間交互的可見性。REST 簡化了客戶端和伺服器的實現。RESTful的實現:RESTful Web 服務與 RPC 樣式的 Web 服務了解了什麼是什麼是REST，我們再看看RESTful的實現。最近，使用 RPC 樣式架構構建的基於 SOAP 的 Web 服務成為實現 SOA 最常用的方法。RPC 樣式的 Web 服務客戶端將一個裝滿數據的信封(包括方法和參數信息)通過 HTTP 發送到伺服器。伺服器打開信封並使用傳入參數執行指定的方法。方法的結果打包到一個信封並作為響應發回客戶端。客戶端收到響應並打開信封。每個對象都有自己獨特的方法以及僅公開一個 URI 的 RPC 樣式 Web 服務，URI 表示單個端點。它忽略 HTTP 的大部分特性且僅支持 POST 方法。由於輕量級以及通過 HTTP 直接傳輸數據的特性，Web 服務的 RESTful 方法已經成為最常見的替代方法。可以使用各種語言(比如 Java 程序、Perl、Ruby、Python、PHP 和 Javascript[包括 Ajax])實現客戶端。RESTful Web 服務通常可以通過自動客戶端或代表用戶的應用程序訪問。但是，這種服務的簡便性讓用戶能夠與之直接交互，使用它們的 Web 瀏覽器構建一個 GET URL 並讀取返回的內容。在REST 樣式的 Web 服務中，每個資源都有一個地址。資源本身都是方法調用的目標，方法列表對所有資源都是一樣的。這些方法都是標准方法，包括 HTTP GET、POST、PUT、DELETE，還可能包括 HEADER 和 OPTIONS。在RPC 樣式的架構中，關注點在於方法，而在 REST 樣式的架構中，關注點在於資源 -- 將使用標准方法檢索並操作信息片段(使用表示的形式)。資源表示形式在表示形式中使用超鏈接互聯。Leonard Richardson 和 Sam Ruby 在他們的著作 RESTful Web Services 中引入了術語 REST-RPC 混合架構。REST-RPC 混合 Web 服務不使用信封包裝方法、參數和數據，而是直接通過 HTTP 傳輸數據，這與 REST 樣式的 Web 服務是類似的。但是它不使用標準的 HTTP 方法操作資源。它在 HTTP 請求的 URI 部分存儲方法信息。好幾個知名的 Web 服務，比如 Yahoo 的 Flickr API 和 del.icio.us API 都使用這種混合架構。RESTful的實現:RESTful Web 服務的 Java 框架有兩個 Java 框架可以幫助構建 RESTful Web 服務。erome Louvel 和 Dave Pawson 開發的 Restlet(見 參考資料)是輕量級的。它實現針對各種 RESTful 系統的資源、表示、連接器和媒體類型之類的概念，包括 Web 服務。在 Restlet 框架中，客戶端和伺服器都是組件。組件通過連接器互相通信。該框架最重要的類是抽象類 Uniform 及其具體的子類 Restlet，該類的子類是專用類，比如 Application、Filter、Finder、Router 和 Route。這些子類能夠一起處理驗證、過濾、安全、數據轉換以及將傳入請求路由到相應資源等操作。Resource 類生成客戶端的表示形式。JSR-311是 Sun Microsystems 的規范，可以為開發 RESTful Web 服務定義一組 Java API。Jersey是對 JSR-311 的參考實現。JSR-311 提供一組注釋，相關類和介面都可以用來將 Java 對象作為 Web 資源展示。該規范假定 HTTP 是底層網路協議。它使用注釋提供 URI 和相應資源類之間的清晰映射，以及 HTTP 方法與 Java 對象方法之間的映射。API 支持廣泛的 HTTP 實體內容類型，包括 HTML、XML、JSON、GIF、JPG 等。它還將提供所需的插件功能，以允許使用標准方法通過應用程序添加其他類型。RESTful的實現:構建 RESTful Web 服務的多層架構RESTful Web 服務和動態 Web 應用程序在許多方面都是類似的。有時它們提供相同或非常類似的數據和函數，盡管客戶端的種類不同。例如，在線電子商務分類網站為用戶提供一個瀏覽器界面，用於搜索、查看和訂購產品。如果還提供 Web 服務供公司、零售商甚至個人能夠自動訂購產品，它將非常有用。與大部分動態 Web 應用程序一樣，Web 服務可以從多層架構的關注點分離中受益。業務邏輯和數據可以由自動客戶端和 GUI 客戶端共享。惟一的不同點在於客戶端的本質和中間層的表示層。此外，從數據訪問中分離業務邏輯可實現資料庫獨立性，並為各種類型的數據存儲提供插件能力。圖1 展示了自動化客戶端，包括 Java 和各種語言編寫的腳本，這些語言包括 Python、Perl、Ruby、PHP 或命令行工具，比如 curl。在瀏覽器中運行且作為 RESTful Web 服務消費者運行的 Ajax、Flash、JavaFX、GWT、博客和 wiki 都屬於此列，因為它們都代表用戶以自動化樣式運行。自動化 Web 服務客戶端在 Web 層向 Resource Request Handler 發送 HTTP 響應。客戶端的無狀態請求在頭部包含方法信息，即 POST、GET、PUT 和 DELETE，這又將映射到 Resource Request Handler 中資源的相應操作。每個請求都包含所有必需的信息，包括 Resource Request Handler 用來處理請求的憑據。從Web 服務客戶端收到請求之後，Resource Request Handler 從業務邏輯層請求服務。Resource Request Handler 確定所有概念性的實體，系統將這些實體作為資源公開，並為每個資源分配一個惟一的 URI。但是，概念性的實體在該層是不存在的。它們存在於業務邏輯層。可以使用 Jersey 或其他框架(比如 Restlet)實現 Resource Request Handler，它應該是輕量級的，將大量職責工作委託給業務層。Ajax 和 RESTful Web 服務本質上是互為補充的。它們都可以利用大量 Web 技術和標准，比如 HTML、JavaScript、瀏覽器對象、XML/JSON 和 HTTP。當然也不需要購買、安裝或配置任何主要組件來支持 Ajax 前端和 RESTful Web 服務之間的交互。RESTful Web 服務為 Ajax 提供了非常簡單的 API 來處理伺服器上資源之間的交互。圖1 中的 Web 瀏覽器客戶端作為 GUI 的前端，使用表示層中的 Browser Request Handler 生成的 HTML 提供顯示功能。Browser Requester Handler 可以使用 MVC 模型(JSF、Struts 或 Spring 都是 Java 的例子)。它從瀏覽器接受請求，從業務邏輯層請求服務，生成表示並對瀏覽器做出響應。表示供用戶在瀏覽器中顯示使用。表示不僅包含內容，還包含顯示的屬性，比如 HTML 和 CSS。 業務規則可以集中到業務邏輯層，該層充當表示層和數據訪問層之間的數據交換的中間層。數據以域對象或值對象的形式提供給表示層。從業務邏輯層中解耦 Browser Request Handler 和 Resource Request Handler 有助於促進代碼重用，並能實現靈活和可擴展的架構。此外，由於將來可以使用新的 REST 和 MVC 框架，實現它們變得更加容易，無需重寫業務邏輯層。數據訪問層提供與數據存儲層的交互，可以使用 DAO 設計模式或者對象-關系映射解決方案(如 Hibernate、OJB 或 iBATIS)實現。作為替代方案，業務層和數據訪問層中的組件可以實現為 EJB 組件，並取得 EJB 容器的支持，該容器可以為組件生命周期提供便利，管理持久性、事務和資源配置。但是，這需要一個遵從 Java EE 的應用伺服器(比如 JBoss)，並且可能無法處理 Tomcat。該層的作用在於針對不同的數據存儲技術，從業務邏輯中分離數據訪問代碼。數據訪問層還可以作為連接其他系統的集成點，可以成為其他 Web 服務的客戶端。數據存儲層包括資料庫系統、LDAP 伺服器、文件系統和企業信息系統(包括遺留系統、事務處理系統和企業資源規劃系統)。使用該架構，您可以開始看到 RESTful Web 服務的力量，它可以靈活地成為任何企業數據存儲的統一 API，從而向以用戶為中心的 Web 應用程序公開垂直數據，並自動化批量報告腳本。什麼是REST:結束語REST 描述了一個架構樣式的互聯系統(如 Web 應用程序)。REST 約束條件作為一個整體應用時，將生成一個簡單、可擴展、有效、安全、可靠的架構。由於它簡便、輕量級以及通過 HTTP 直接傳輸數據的特性，RESTful Web 服務成為基於 SOAP 服務的一個最有前途的替代方案。用於 web 服務和動態 Web 應用程序的多層架構可以實現可重用性、簡單性、可擴展性和組件可響應性的清晰分離。Ajax 和 RESTful Web 服務本質上是互為補充的。

⑶ 如何理解spring boot中的微服務架構的體現

1. Spring Boot是什麼，解決哪些問題
1) Spring Boot使編碼變簡單
2) Spring Boot使配置變簡單
3) Spring Boot使部署變簡單
4) Spring Boot使監控變簡單
5) Spring Boot的不足
2. Spring Boot在平台中的定位，相關技術如何融合
1) SpringBoot與SEDA +MicroService + RESTful
2) SpringBoot與Mock
3. 採用了SpringBoot之後，技術管理應該如何進行

首先，我們來看一下spring boot是什麼，它幫助我們解決了哪些問題：

SpringBoot是伴隨著Spring4.0誕生的；
從字面理解，Boot是引導的意思，因此SpringBoot幫助開發者快速搭建Spring框架；
SpringBoot幫助開發者快速啟動一個Web容器；
SpringBoot繼承了原有Spring框架的優秀基因；
SpringBoot簡化了使用Spring的過程。

Spring由於其繁瑣的配置，一度被人認為「配置地獄」，各種XML、Annotation配置，讓人眼花繚亂，而且如果出錯了也很難找出原因。
Spring Boot更多的是採用Java Config的方式，對Spring進行配置。

可以看到，採用了spring-boot-start-actuator之後，直接以REST的方式，獲取進程的運行期性能參數。
當然這些metrics有些是有敏感數據的，spring-boot-start-actuator為此提供了一些Basic Authentication認證的方案，這些方案在實際應用過程中也是不足的。

Spring Boot作為一個微框架，離微服務的實現還是有距離的。
沒有提供相應的服務發現和注冊的配套功能，自身的acturator所提供的監控功能，也需要與現有的監控對接。沒有配套的安全管控方案，對於REST的落地，還需要自行結合實際進行URI的規范化工作。
下面，我們研究一下Spring Boot在平台中的定位，相關技術如何融合。

⑷ 為什麼選擇Spring Boot作為微服務的入門級微框架

⑸ java微服務架構有哪些

String boot 微型架構首選面xml配置一路使用默認的話你只需要寫核心邏輯,導出jar包就可以直接放在伺服器上用

⑹ SOA和微服務架構的區別

SOA與微服務架構，在架構劃分、技術平台選擇等方面，均存在一定的區別。

一、架構劃分不同

1、SOA強調按水平架構劃分為：前、後端、資料庫、測試等；

2、微服務強調按垂直架構劃分，按業務能力劃分，每個服務完成一種特定的功能，服務即產品。

二、技術平台選擇不同

1、SOA應用傾向於使用統一的技術平台來解決所有問題；

2、微服務可以針對不同業務特徵選擇不同技術平台，去中心統一化，發揮各種技術平台的特長。

三、系統間邊界處理機制不同

1、SOA架構強調的是異構系統之間的通信和解耦合；（一種粗粒度、松耦合的服務架構）；

2、微服務架構強調的是系統按業務邊界做細粒度的拆分和部署。

四、主要目標不同

1、SOA架構，主要目標是確保應用能夠交互操作；

2、微服務架構，主要目標是實現新功能、並可以快速拓展開發團隊。

參考資料

網路-SOA

網路-微服務架構

⑺ 微服務架構有哪幾種常用的設計模式

自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構現有的「單體應用（monolithic application）」時，SQL資料庫反規范化可能會導致數據重復和不一致。因此，在單體應用到微服務架構的過渡階段，可以使用這種設計模式，

⑻ 微服務是如何演變的，又為什麼重要

微服務的概念產生是順應這樣的需求：為了開發出速度更快、更有彈性且用戶體驗更佳的應用。這個概念等同於具有可擴展性的自動化系統，在簡單的商業化架構上運行軟體。由於容器所提供的經濟效率，在2016年微服務將是一大主題。

應用快速開發的需求影響到了全部公司，以及如何看待歷來業務安排的方式。來自微服務的新實踐代表著需要小型團隊以對於公司來說陌生的方式——自上而下進行迭代。這意味著企業運作的方式將獲得徹底的改變。

現在在針對應用架構與微服務的新思考方面，容器生態系統逐漸成為核心主題。根據Battery Ventures技術人員Adrian Cockcroft的說法：關於微服務有一些基本的原則需要思考。首先，如今構建軟體的價格更為低廉，容器的出現降低了成本。Docker被所有人納入藍圖——從軟體供應商到終端用戶，所有人都在嘗試找出容器的用法，因為用它就能加快軟體的交付節奏。不過這也代表著要安裝的系統是應用級別的，也就是說在應用的開發、部署與管理方面出現了不同的需求。

Adrian Cockcroft在面向對象軟體架構大會上關於微服務的演講，以卡通形式呈現，作者是Remarker

舉個例子，對於要處理服務與堆棧范圍增長的公司來說，監控比以往更加重要。要想解決問題，必須對數據日誌進行分析，而這些日誌很可能橫跨臨時節點與多項服務。由於需要細化監控與加強工具，從業人員能更好地掌握這些構建模塊對於應用所依賴的許多潛在微服務的影響。

那麼起作用的是什麼呢？從公司與API開始：基於微服務的產品團隊與另一個基於終端的平台團隊之間靠API連接，通過API調用以及企業基礎架構持續作出相應的回應來生效。

微服務被定義為特定背景下松耦合、面向服務的架構，允許在無需理解其他部件運作原理的情況下進行更新。整個服務是跨公司構建的，但所有權卻在同一個地方。微服務架構提供了更多系統間的點對點調用。消息形式必須靈活，所有部件在無論哪個版本中都能運作。這意味著在構建微服務架構時，我們需要一些工具來配置、探索、輸送流量、觀察與構建系統。

IBM傑出的工程師兼IBM雲計算中心的CTO Andrew Hately作出了類比：15年前人們可能需要每周查看一下自己的銀行余額，而互聯網允許人們實時查看余額甚至做出進一步操作，也許隨著智能手機的發展，很多事情都發生的改變。如今，人們可以即時訪問自己的賬戶收支信息。這種速度與即時性代表著：在過去的5-10年內，企業提供服務的發展速度必須跟得上社交網路與搜索公司發展的速度。

公司必須處理員工、消費者、系統與所有可能組合之間的持續互動——就像Hately所說的完全互聯與持續可用。這意味著企業流程需要重建，需要將所有東西連接起來。如果公司不進行這方面的嘗試，也無法提供相應功能的話，很快就會面臨收入減少甚至出局的局面。

Hately表示：「工具非常關鍵。」 有數百家網站不支持代碼，收到反饋後，在下一組測試用例中消費者就能使用它了。這種嚴格的開發過程提供了一種企業工作方式，也為微服務發展提供了思考方式。DevOps中的ops也會執行這樣的工作。如果你有一小段代碼並為其定義指標的話，就能細分出哪些會成功，哪些會失敗。

IBM通過為消費者及內部團隊構建反饋通道與成功標准，在敏捷、DevOps、精益生產與其他迭代進程中結合最佳實踐，創建了名為IBM Bluemix Garage Method方法的企業方法論。IBM Bluemix Garage Method方法將企業解決方案的可靠性及可測試性與最新開放社區在規模質量上的最佳實踐結合起來，持續創新、創建持續交付渠道並在雲平台上進行部署。這種方法很有價值，向所有人開放資源能夠提高個人、團隊與全公司的DevOps技能，以及管理與監控能力。

軟體相關的契約

第一代的容器管理平台支持這些速度更快的開發進程。Docker的產品高級VP Scott Johnston表示，在Docker Compose中，微服務促進了工具發展，YAML文件扮演了描述不同組件的清單（manifest）。Compose讓開發人員得以用抽象的方式描述多容器應用，它可以描述web容器、資料庫容器、負載均衡及其間的邏輯關系，無需連網或部署存儲。

Engine Yard的Matt Butcher表示：微服務是軟體相關的契約。有些人會辯稱微服務是正確執行的面向服務架構（SOA）。開發者想要的是有用、功能豐富且結構優雅的架構。微服務使得軟體開發回歸Unix的根源——將一件事完成得很好。用Unix可以任意輸出命令。微服務不止在如何優秀地完成工作方面，同時在如何與環境互動方面也表現出契約性。如果運行良好，它所做的工作就像是優秀的Unix shell腳本。

舉個例子，Kubernetes清單文件格式扮演著契約的角色，這個清單提供了所需的來源細節、存儲卷定義、存儲需求等，扮演了強大的DevOps類契約。它讓開發者和運營者了解想要的內容。開發者與運營者之間的關系不再如同之前那樣——開發者被迫只管自己的一攤工作。

一張清單可能會包括應用元數據，加上具體版本的描述性參數，其中可能還有多個清單。也許是一個實例、一個pod清單、一個復制控制器（replication controller）或者一個服務定義，還有組成文件的已知來源位置。任意標簽可能由圖表中所包括的組件來定義。

Butcher表示：「應用開發者在這方面的體驗夠深刻了。一旦出現典型問題，就會說丟過牆去，各管各的，反正有DevOps來負責生產環境中的運行事宜，開發者只負責開發，總有一個切換過程，往往會成為各掃門前雪的後果。」

如果開發者構建容器，會存在一定的水平保證（由抽象層決定）：這些容器的運行方式在生產階段與開發階段是一樣的。這已經緩解了讓懂得容器這個基本工具的DevOps專業人員感到頭疼的大多問題。容器化已經提供了這種保障，不過像Helm（Engine Yard所提供的新服務）之類的產品有助於進一步規范化這種關系，具體表現為團隊間的契約形式——團隊成員不能再推卸責任，各掃門前雪了，而要全程參與。

從虛擬機與Monolith，到容器，再到微服務

根據Joyent的CTO Bryan Cantrill的說法：容器為原生雲架構提供了基礎，與傳統的虛擬化形式相比，象徵著一種新的應用架構形式。在使用較大的機器來進行計算時，基於硬體的虛擬化或者傳統虛擬機流行過一段時間。虛擬機為運營團隊提供了管理大型整體應用的方式，就像Cantrill說的「過於臃腫」，而硬體定義了企業架構。虛擬機建議在底層之上，承擔了運營系統的負載。但是容器創建了一個全新而更敏捷的抽象。就是Cantrill的那句話：「應用繼續減肥速成修煉。」

如今，唯一的麻煩在於如何將虛擬機和monolith換成容器和微服務。各家公司還在想方設法執行這種轉變，因為兩種方式對應用架構、基礎設施還有公司自身整體的思路都是迥異的。

Cantrill表示：Joyent的開源Triton服務，其目的就是為了簡化與加速公司向容器與微服務的轉變。它允許開發者簡化架構，只提供容器，不提供虛擬機。由於無需配置網路等操作，用戶可以通過閱讀微服務手冊，在短時間內完成部署。

Cantrill表示，Joyent公司是Docker Compose的粉絲，因為Compose可以用來與單獨的Docker Engine通訊。Docker的遠程端點由Triton部署，從而虛擬化了整個數據中心。使用這些工具，很容易快速讓一個完整有彈性的運營服務運轉起來。正如Cantrill所言：「這是大勢所趨。」

VMware的CTO Kit Colbert從如何沿著容器之旅前進的角度來觀察市場。VMware著重運營領域。現在它開發了一種方式，來滿足新的開發人員及其需求，不過是作為基礎架構提供商存在。

對於VMware來說，這家公司將自己視為基礎設施提供商，而不是以應用為中心、面向架構的公司。Colbert只看到了對Cloud Foundry感興趣的消費者，不過也有人想要DIY的方法。VMware正在設法通過vSphere集成容器（VIC）與Photon平台對應用技術提供支持。

為了讓消費者適應使用容器，vSphere集成容器（VIC）讓容器化工作負載稱為vSphere的重中之重。VIC適合在開發進程中運行，將容器化最有價值的一個方面應用在容器中：靈活並具有動態的資源界限。通過虛擬化，VMware將普通硬體轉化為簡單、可取代的財產。同樣，通過在虛擬機中應用Docker端點，vSphere集成容器創建了完全動態邊界的虛擬容器主機。結果就是對傳統與基於微服務應用同樣支持的基礎架構，允許IT與開發者的訪問。

相比之下，VMware的Photon平台是專為原生雲應用設計的。Photon平台由最小的管理程序與控制面板組成，專為微服務提供速度與規模的服務。Photon平台在設計時還考慮到了開發者通過API使用時的易用性，讓這個平台成為一個提供應用程序與快速部署的自助服務平台。

從VMware的角度來說，運營團隊也在推進部署速度。現在更著重於數字化體驗或者軟體如何提供更多功能方面。很類似我們如何看待在智能手機上使用的應用。供應商可能以聲音很大的揚聲器而聞名，不過服務的應用是否能提供功能？

Colbert詢問：「我能依賴它嗎？」 公司必須找出構建應用，為尋找高質量應用的消費者提供服務的方式。想要繼續進步，就必須找到這一點。很多擁有外置式、虛擬化基礎架構的消費者希望：隨著應用開發進程的加快，解決公司面臨的挑戰。

在微服務時代的開發

軟體開發是迭代式的，需要持續的反饋循環才能奏效。這也是類似IBM Bluemix Garage Method所提供的工具所提供的功能。不過大多公司是根據模型來執行的，這與開發者工作的方式不同。開發者不會按照銷售、市場推廣、財務等部門人員的方式來工作，開發者不是按照計劃或方案來執行工作的。軟體開發的過程有更多的迭代，並非瀑布式自上而下的。

Pivotal的首席技術Michael Coté表示：「我不知道怎麼說，不過真實世界與軟體世界是完全不同的。」Coté辯稱：找出軟體開發的方式似乎非常矛盾，不過事實上確實阻止了人們想要根據一份文檔來了解一個巨大機器的所有部件的工作方式。通過遵守軟體開發的原則，各家公司找到了自己的辦法，而不是嚴格遵守固定的計劃。

Coté認為，沒有執行微服務的固定道路。用微服務可以在運行中和架構上獲得靈活性。微服務根據簡單的原則構建出真正復雜的東西。原則越簡單，所能創造的東西就越復雜。

不過，如果把復雜性轉移到其他地方會發生什麼？Pivotal這個平台管理著復雜程度。去掉選擇，讓消費者無需考慮網路、運營系統等問題。它允許消費者將復雜性放在應用堆棧的頂層，在為終端用戶提供服務時能夠更好的區分服務。Hately表示：「在科技行業，我們看到了另一個文藝復興時期。」

同樣地，IBM Bluemix Garage Method也希望簡化復雜性，以便讓開發者的工作更有效率，能夠更好地享受自己的工作。所有這些努力都為企業提供了巨大的機會，無論在技術還是文化層面。