微服務docker

① 微服務為什麼要選擇docker

我最近在玩Docker，一種應用程序容器和Linux的虛擬技術。它太酷了，創建內Docker鏡像和容器只需要幾容分鍾。所有的工作都是開箱即用的。 在結束我一天的工作之前，我希望能保存下我的工作。但我在Docker的save和export命令之間，我凌亂了。我不知道...

② 微服務為什麼一定要用Docker

早在2013年的時候，就已經發行，然而那會還是很少人了解docker。一直到2014年，Martin Fowler提出了微服務的概念，兩個不相乾的技術終於走在了一起，創造了今天的輝煌！

現在:用上了docker容器後，將Docker可以將我們的應用程序打包封裝到一個容器中，該容器包含了應用程序的代碼、運行環境、依賴庫、配置文件等必需的資源。容器之間達到進程級別的隔離，在容器中的操作，不會影響道宿主機和其他容器，這樣就不會出現應用之間相互影響的情形！

③ 微服務如果不部署在docker可不可以

微服務只是來 架構設計理念 跟這些都源沒有關系 不用這些也可以實現 就一般分布式集群那套就可以了 微服務只不過再把服務 分的細一點 (5個月前) VenyoWang但是Docker也需要運行程序才能提供服務，我想問的就是用WCF來提供微服務是否

④ 如何在Python中使用ZeroMQ和Docker構建微服務架構

當想讓一個容器做兩件事情，或者使一個Docker鏡像包含來自兩個不同鏡像的依賴庫時，就需要知道每個鏡像的Dockerfile。本文介紹了如何通過docker history命令來對Docker鏡像進行反向工程，得到它們的Dockerfile，並組織到一個Dockerfile里然後build，從而實現想做的事情。

常言道，「不要重復發明輪子！」

在使用Docker時，構建自己的鏡像之前，最好在Docker Hub尋找一些可以直接使用的鏡像做練習。把軟體架構分布到一系列容器中，每一個容器只做一件事情，這樣的效果非常好。構建分布式應用的最好的基石是使用來自Docker Hub的官方鏡像，因為可以信任它們的質量。

在某些情況下，可能想讓一個容器做兩件不同的事情。而在另外一些情況下，可能想讓一個Docker鏡像包含來自兩個不同鏡像的依賴庫。如果有每個鏡像的Dockerfile，這是非常簡單的。將它們組織到一個Dockerfile里然後build就行。

然而，大多數時間都在使用Docker Hub上准備好的鏡像，不會有它們的源Dockerfile。我花時間找一個可以合並（或flatten）兩個不同Docker鏡像的工具，當然沒有它們的Dockerfile。也就是說在找一個能做下面這件事的東西：
image 1 --
\
---> merged_image_12
/
image 2 --

此前在GitHub上有兩個相關的討論（1、2），盡管它們都被關閉了。

這可能嗎？
那麼，是否存在工具能夠像這樣做嗎：docker merge image2 image2 merged_image？

沒有！
你甚至不可以用下面的方式來構建Dockerfile：
FROM image1
FROM image2

簡而言之，在一個Dockerfile里不能有多個基礎鏡像。

但是我需要這個功能！
唯一的解決辦法是取得這些鏡像的Dockerfile，然後把它們組織到一個文件中，再進行構建。那麼，我能在Docker Hub上獲得一個鏡像的Dockerfile嗎？ 幸運的是可以。它不能離線獲取（譯註：原文是online，但顯然online時對於來自GitHub的自動構建鏡像是可以直接獲取的），但是你可以使用docker history命令，通過反向工程獲取。

怎麼來使用？
在你的機器上使用docker pull從Docker Hub下載鏡像。
docker pull image1
docker pull image2

然後使用docker history來取得構建這兩個容器時運行的命令。
docker history --no-trunc=true image > image1-dockerfile
docker history --no-trunc=true image2 > image2-dockerfile

接下來打開這兩個文件，你可以看到每個鏡像的命令堆棧。這是因為Docker鏡像通過層（閱讀更多）的方式來構建。即你在Dockerfile中鍵入的每一個命令所構建的新鏡像，都是在之前的命令產生的鏡像之上。所以你可以對鏡像進行逆向工程。

限制
不能對鏡像進行反向工程的唯一場景，是鏡像的維護者在他的Dockerfile中使用了ADD或COPY命令。你會看到這樣一行：
ADD file:1ac56373f7983caf22
或 ADD dir:cf6fe659e9d21535844
這是因為不知道維護者在他自己的機器上，包括鏡像里使用了什麼本地文件。

⑤ 使用Docker 構建微服務架構，服務與服務之間的通信有什麼最佳實踐

服務與服務之間的通訊現在大部分是用的Http+Rest的方式來處理的,但是當服務個數的增加專真的不知道為屬出現什麼問題,現在好像也沒有哪個公司的量級到了這個出現問題的程度,相反,我覺得是用SOA的方式來管理服務與服務之間的通訊未必不是一件壞事,畢竟好用才是王道.針對這個問題我也有一篇blog說明,你可以看看: 微服務之間介面調用的一種新架構思路 歡迎拍磚 補充:這個架構是面向連接的,不是面向數據的

⑥ docker鏡像多個微服務公共代碼怎麼用

潤物細無聲。

⑦ docker鏡像中的微服務怎麼訪問宿主機上的oracle資料庫呢

在home上安裝一個oracle客戶端，配置好鏈接文件

⑧ SpringCloud與Docker微服務架構實戰PDF下載

使用Spring Cloud構建實際的微服務架構。 基本概念: 使用Docker進行集成測試 混合持久化 微服務架構 服務發現內 API網關 Docker 使用Docker對每一容個服務進行構建和部署。使用Docker Compose在一個開發機上進行端到端的集成測試。

⑨ 如何使用 Java 和 Docker 構建微服務

在Java生態中，構建微服務的策略包括Container-less，Self-contained，以及In-container等。
Container-less微服務將應用及其依版賴打包成一個單一的權jar文件。
Self-contained微服務也是打包成一個單一的Jar文件，但它還包括一個嵌入式框架，這個框架含有可選的第三方lib，當然這些lib是兼容的。
In-container微服務打包成一個完整的Java EE容器，該服務在Docker鏡像中實現。 基於微服務的架構給架構師和開發者帶來了新的挑戰，然而，隨著語言的升級和工具數量的增加，開發者和架構師完全有能力應對這樣的挑戰。Java也不例外，本文探討了在Java生態系統內構建微服務的不同方法。

⑩ 如何在Python中使用ZeroMQ和Docker構建微服務架構

微服務是什麼？

微服務是一種架構風格，它包括多個彼此間進行通信的獨立進程。在設計上，這些進程具有高度的可擴展性、相互解耦而且一次只完成一個較小的任務。這些服務都擁有自己的資源以及通過網路實現彼此間通信的進程。

相比於靠後端的 單體結構
來封裝所有伺服器邏輯的傳統客戶端－伺服器架構（C/S架構）而言，微服務架構的差異性體現在關注點分離（Separation of
concern）。這種設計模式更易於維護，使得靈活性、可擴展性及容錯能力更強。但是這種分布式架構所的不足之處體現在如果設計不合理就會使得排錯及維
護變得復雜。

一個簡單微服務的例子

讓我們來分析這樣的一個場景：你正在使用微服務模式構建一個電子商務網店。

對於一個電商網店上的常見商品，好比說iPhone，其詳情頁會顯示：

。產品的及基本信息

。你的購買歷史

。哪些人買了iPhone也買了手機套

。與蘋果手機相關的優惠和折扣

。店家的數據

。送貨方式

。推薦商品等等

此外，這個簡單的產品詳情頁的介面將有多個版本的來匹配web、移動端以及用於第三方應用程序的REST API。

在微服務模式中數據分布在多個服務之間。在這個例子中，服務包括：

。產品詳情服務

。商家服務

。支付服務

。優惠及折扣服務

。庫存服務

。定價服務

。回顧服務

。推薦服務

這些獨立的服務是如何被訪問的呢？

解決辦法是使用一個API網管，它作為所有客戶端的單一入口並且根據需求調用分布在整個基礎架構中的特定微服務。以上模式的行業應用案例是NetFlix API網關，它具有支持不同設備的多個API客戶端。你可以點擊此處 了解更多 。

構建一個簡單的微服務

目前有很多方法可以用於構建你的微服務。

在本文中我們將使用ZeroMQ來創建兩個進程之間的通信。ZeroMQ提供了用於在套接字之上開發可擴展、分布式systed的構建塊。它使用橢圓曲線密碼體制（第四版）來實現安全性，並提供了即刻開啟的 通訊模式 。

關於ZMQ，還有很多 優點 。MQ即是針對非同步工作而設計的線程化消息隊列。談論太多zeroMQ的內容已經超出了本文的范疇，你可以閱讀 使用zeromq 以及 zeromq用於分布式系統 。

我們要使用的另一個工具是 Docker 。本文假設讀者對Docker已經有了基礎的了解。

ZeroMQ有很多種通訊模式，為了開始我們的工作，讓我們用ZeroMQ和Flask來配置一個簡單的PUB－SUB。下圖展示了組件之間的關系和數據流。

1&3 － 一個flask伺服器運行在5000埠上而且其URL是 /downcase/ 。該URL用來接受（GET）請求，而所有格式為的請求將收到回應：答謝字元將會轉換為小寫字元並返回。

2 － 回應的消息也被發送給同一個容器中的ZMQ發布者（Publisher）

4，5 － ZMQ訂閱者（subscriber）持續監聽並將來自ZMQ伺服器的消息保存到名為 subscriber.log 的文件中

創建伺服器

首先看一下我們的Dockerfile

<pre><code>

FROM ubuntu:14.04

RUN apt-get update

RUN apt-get install -y --force-yes python python-dev python-setuptools software-properties-common gcc python-pip

RUN apt-get clean all

RUN pip install pyzmq

RUN pip install Flask

ADD zmqserver.py /tmp/zmqserver.py

Flask Port

EXPOSE 5000

Zmq Sub Server

EXPOSE 4444

CMD ["python","/tmp/zmqserver.py"]

</code></pre>

我們選擇Ubuntu
14.04作為容器操作系統。我們安裝了基本的軟體包。通過pip，我們安裝pyzmq（zeromq的Python綁定）同時也安裝了Flask。接著
我們導出埠5000（flask伺服器）和4444（發布者運行的埠）。此外，我們復制了包含所有flask及zeromq
pythond代碼的腳本文件 zmqserver.py 並運行它。

現在我們來看一下zmqserver.py的內容：

server.py

import time

import zmq

HOST = '127.0.0.1'

PORT = '4444'

_context = zmq.Context()

_publisher = _context.socket(zmq.PUB)

url = 'tcp://{}:{}'.format(HOST, PORT)

def publish_message(message):

try:

_publisher.bind(url)

time.sleep(1)

_publisher.send(message)

except Exception as e:

print "error {}".format(e)

finally: _publisher.unbind(url)

from flask import Flask

from flask import request

app = Flask(__name__)

@app.route("/downcase/", methods=['GET'])

def lowerString():

_strn = request.args.get('param')

response = 'lower case of {} is {}'.format(_strn, _strn.lower()) publish_message(response)

return response

if __name__ == '__main__':

app.run(host='0.0.0.0', debug=False)

ZMQ發布者運行在4444埠上。我們創建了一個context並且聲明了URL。我們運行了flask app，它通過URL ／downcase/ 把GET獲得的參數 Param 轉換成小寫字元，這就是服務的應答。應答的字元串是 published ，它作為一個消息把相同的字元串返回給瀏覽器。

為了構建以上的Docker映像（image），我們執行以下的命令：
sudo docker build -t docker-zmq-pub

並且在該映像之上執行：
docker run --name docker-pub-server -p 5000:5000 -p 4444:4444 -t docker-zmq-pub

我們把容器中的埠5000和4444映射到這台主機上，於是無論客戶端在哪裡，它們都可以訂閱這個發布者。

訂閱者客戶端

client.py

import zmq

import sys

import time

import logging

import os

HOST = '127.0.0.1'

PORT = '4444'

logging.basicConfig(filename='subscriber.log', level=logging.INFO)

class ZClient(object):

def __init__(self, host=HOST, port=PORT):

"""Initialize Worker"""

self.host = host

self.port = port

self._context = zmq.Context()

self._subscriber = self._context.socket(zmq.SUB)

print "Client Initiated"

def receive_message(self):

"""Start receiving messages"""

self._subscriber.connect('tcp://{}:{}'.format(self.host, self.port))

self._subscriber.setsockopt(zmq.SUBSCRIBE, b"")

while True:

print 'listening on tcp://{}:{}'.format(self.host, self.port)

message = self._subscriber.recv()

print message

logging.info(

'{} - {}'.format(message, time.strftime("%Y-%m-%d %H:%M")))

if __name__ == '__main__':

zs = ZClient()

zs.receive_message()

我們聲明了發布者的IP地址及埠，當前它運行在同一個的主機上因此地址是127開頭。我們在URL tcp://IP:PORT 上進行監聽。一旦我們收到一個消息，就將其附上時間戳後記錄到名為 subscriber.log 的文件中。運行客戶端要做的所有工作就是執行 python <name_of_client_file>.py 。如果你在以上的架構上進行構建，它可以很好地充當近實時的日誌聚合引擎。

我在Unbuntu主機上對以上的代碼進行了測試。這里所用的代碼保管在 github 上。這是一個如何配置zmq、docker和python伺服器的基礎講解，在我的下一片文章中我們會使用我們已經學習的東西構建簡單的微服務。