[Day 2] 據說你沒來 JSConf 2017？

上海 2017 JSConf 大會已經結束，整理的兩天大會實錄以下：

• 2017 JSConf 第一天實錄
• 2017 JSConf 次日實錄

第一場：Node.js Microservices on Autopilot

開場簡單介紹了一下什麼是微服務。

微服務有什麼幫助

• 假想步驟：

  • 把 corn 服務分解成許多較小服務
  • 每一個微服務均可以獨立部署
  • 新的微服務均可以負載均衡

• 當微服務架構與他們所替代的服務相同時，它們也會面對相同的挑戰。

微服務的優點

• 容忍失敗，儘管外部失敗後仍可工做。

• 快速迭代，一次性服務，可獨立部署服務。

微服務的反模式

• 微服務器之間須要負載平衡器

• 啓動順序很重要

• 負載平衡無處不在。

Autopilot 模式

• 能夠經過單擊來部署和擴展的應用程序。

• 應用和工做流在咱們的筆記本電腦和在雲（公有或者私有云）上一樣工做

• 應用和工做流不用強綁在任何特定的架構或者調度上。

Autopilot 應用

• Autopilot 模式的解決方案
• 能夠經過 Container 獲取服務

Autopilot 實踐

• 應用程序由編寫的 docker 容易組成
• 服務探索能夠用過 consul 或者其餘 catalog
• Container 本地健康和服務相應於服務依賴的變化

ContainerPilot

• 自動化一個 Container 的服務探索，生命週期管理和遙測報告
• 功能
  • Container-local 健康檢查
  • PID 1初始化進程
  • 服務探索和註冊和觀察
  • 遙測報告給 Prometheus
  • 免費以及開源 github.com/joyent/containerpilot

一些 tips ：

• 防止那些會發生並會致使服務負擔太重的請求。
• 一旦達到相應超時的閾值，阻止之後的服務直到服務可以跟上處理或者恢復
• 是否可使用負載均衡器實現？

load Balancers at Edge

• 不要將微服務直接暴露在你的組織之外。
• 設置一個可以使用 Consul 的負載均衡器。
• 當經過微服務創造商業價值時 API 網關也比較重要。

第二場： 無服務器架構與API

函數即服務

軟件開發須要考慮如下幾點：

• 可運維性

• 可拓展性

• 安全性

• 穩定性

• 可靠性

• 高可用性

Xaas 比較

函數計算的應用架構及執行方式

API Gateway & Function Computing

API Gateway 的特色：

• 防攻擊，防重放，請求加密、身份認證、權限管理、流量控制

• API 定義、測試、發佈、下線生命週期管理

• 監控、報警、分析、API 市場

Faas 的缺陷

• 運行環境的不肯定性：IP變化

• 運行環境的數量，對依賴資源的壓力：好比數據庫的鏈接數的限制。

第三場：從 REST 到 GraphQL

GraphQL 一個用於 API 的查詢語言。

一個簡單的 GraphQL query

頁面加載時間 = 加載代碼 + 加載數據

Web 開發的變遷

早期的 Web 開發：

一個 Web 服務器返回靜態的 html 返回給瀏覽器。

2017年的 Web 開發

Web 服務器返回代碼，用戶服務、Posts服務、外部 API 返回數據給瀏覽器。頁面會有不少請求，請求各類數據。如今又多了多個終端，瀏覽器，iOS，Android。

純 REST - 一個endpoint對應一個資源

優勢：

• 靈活
• 解耦

缺點

• 須要不少次請求
• 會獲取到不須要的數據
• 複雜的客戶端

類 REST - 一個endpoint對應一個視圖

優勢：

• 一次請求
• 所得即所需

缺點：

• 不夠靈活
• 高度耦合
• 很高的維護代價
• 迭代緩慢

咱們須要：

• 只須要一次請求
• 所得即所需
• 靈活
• 解耦合

而 GraphQL 能帶給咱們：

• 只須要一次請求
• 所得即所需
• 解耦合

GraphQL 有如下3點重要的特性：

• 一個用來描述數據類型和關係的 API 定義語言
• 一個能夠描述具體須要獲取哪些數據的查詢語言
• 一個能夠 resolve 到數據單個屬性的可執行模型

GraphQL resolvers 約等於 REST endpoints

GraphQL 是一個規範，不是一個實現，它在 servers、clients、tools 這些地方都有相應的規範。

第四場：經過React Storybook實現visual testing驅動開發

這一場講師分享了不少項目中實戰踩坑經驗，感興趣的話，建議你們直接看看回看視頻。

第五場：Graduating your node.js API to production environment

咱們期待的架構類型

什麼是生產系統？

有真實用戶和數據的系統，日用戶至少上千的公開服務。

達到生產級別的水準是？

• 開發者：代碼能夠跑，功能測試均可以經過

• 商業經理：系統能運行，並能給用戶帶來價值和利潤。

• 庫開發者：本身的庫被普遍應用。有很好的文檔。

• 運維：運行時環境穩定，可debug，可維護

• 安全專家：系統經過安全監測。

避免責任缺失

編寫產品級代碼的必要條件

• 穩定
• 有效
• 可調試

如何跨組件跟蹤日誌

只是debug是不夠的

如何在上游服務故障中存活

Add error handling

如何運行 性能/穩定性 測試

安全性

總結

Thinking：

• 考慮產品上線的各個方面
• 避免責任缺失

Code：

• 適當的日誌
• 處理服務故障
• 記錄錯誤內容
• 管理鏈接

系統：

• 作性能和穩定性測試
• 不要獨自去實現全部安全相關的邏輯

第五場：基於 Node.js 開發物聯網應用

物聯網開發

數據產生 -> 傳感器
數據收集 -> 網絡傳輸
數據分析 -> 雲服務器
執行分析結果 -> 執行機構/推送

爲何選用 Node.js ？

• 生態
• 高併發
• 易擴展
• 學習曲線
• 開發效率
• 先後端溝通

最後講師現場演示了一個小車的例子，經過網頁上發送前進、後退、左轉、右轉控制小車的行爲。

第六場：Upgrading to Progressive Web Apps

黃玄老師本次分享的內容不少，滿滿的都是乾貨。強烈建議你們去看黃玄老師的幻燈片：huangxuan.me/jsconfcn201…

本系列筆記是現場記錄的，比較倉促，有些地方會存在誤差或理解錯誤，還請關注官方後續發佈的講師 PPT 和大會視頻。

JSConf China 2017 完美落幕！

整理者 @根號三、@一縷殤流化隱半邊冰霜