demo執行環境：Windows10，Docker(dapr_zipkin，dapr_redid，dapr_placement)

　　安裝：dapr init
　　解除安裝：dapr uninstall，然後刪除 C:\Users\當前使用者\.dapr

　　dapr在部署時是通過給服務掛載一個sidecar，來輔助應用服務來完成一些額外的分散式工作，可以做到無侵入，本例是本地部署，sidecar和應用服務都是獨立程序。通過如下代命令啟動sidecar，appid為app1，應用服務埠是5000，dapr的埠為3500。

dapr ru n --app-id app1 --app-port 5000 --dapr-http-port 3500

　　這種完全的分離，對應用來說是無侵入的，即使把舊應用管理起來也是無縫的。

　　dapr的服務是通過下面這樣的url呼叫的的：

　　http://localhost:3500/v1.0/invoke/app1/method/test

　　3500是dapr埠，其中appid是 app1，對應的介面是 /test ，其他部分就是相同的了，這樣帶來的好處是顯而易見的，沒有的IP或主機名，方便通過 XX應用的XX介面的方式呼叫其他服務。就像訂單服務的下單介面呼叫支付服務的支付介面一樣明確易用。

　　dpar的服務呼叫就這麼簡單，帶來一個問題是，既然dapr可以通過appid做到服務發現，那麼同一服務的多副本怎麼實現？

　　這個問題我沒有從dapr中找到答案(如果您有方案，請告知，十分感謝)，可能也沒有答案，因為dapr說它是應用開發執行時，而不是分散式基礎設施，像負載均衡這種提高可用性的部署，不屬於dapr的範疇。

　　於是我就用nginx搭建了個負載均衡，指向兩個相同的服務。5000是nginx對外的埠，appid為app1；兩個服務埠和appid分別是5001和app1-1，5002和app1-2，後然分別給這三個服務加上sidecar（當然，只對於服務呼叫來說，可以只給nginx加sidecar，但dapr的sidecar不只服務呼叫，還有別用，後續說明）

　　呼叫示意圖如下，如果從瀏覽器呼叫到服務的話，是經過nginx的saidecar和nginx兩層反向代理完成的。

　　經過兩個反向代理，效能會差嗎？為了瞭解呼叫的效能，下面進行了一個測試，1、直接呼叫服務Invock方法；2、經過sidecar代理呼叫服務SidecarInvoke;3、經過nginx的sidecar到nginx，再呼叫服務。下面是呼叫的程式碼：

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

BenchmarkRunner.Run<TestInvock>();

[MemoryDiagnoser]
public class TestInvock
{
    readonly HttpClient _invockClient;
    readonly HttpClient _sidecarClient;
    public TestInvock()
    {
        _invockClient = new HttpClient();
        _sidecarClient = new HttpClient();
    }

    [Benchmark]
    public async Task<string> Invoke()
    {
        var content = await _invockClient.GetStringAsync("http://localhost:5000/test");
        return content;
    }

    [Benchmark]
    public async Task<string> SidecarInvoke()
    {
        var content = await _sidecarClient.GetStringAsync("http://localhost:3500/v1.0/invoke/app1-1/method/test");
        return content;
    }

    [Benchmark]
    public async Task<string> LoadbalancingInvoke()
    {
        var content = await _sidecarClient.GetStringAsync("http://localhost:3500/v1.0/invoke/app1/method/test");
        return content;
    }
}

效能的測試結果：負載均衡後的呼叫還不錯，沒有想的那麼效能差，為了提高效能，可以用gRPC。

　　所得：在學習過程中，一直錯覺dapr能完成服務治理，但實踐下來的結果是：dapr就是分散式開發的執行時。

　　所以使用dpar時，默唸10次：dapr是分散式開發執行時！！！