序言 Nacos官方文檔上有詳細的中文描述,這裏會抄錄下一些我感興趣的(抄錄的時間爲2019-12-03的版本).然後在Centos7上使用git的形式去部署Nacos集羣環境 Nacos介紹 概述 Nacos 是阿
dubbo Alibaba 開源給apache 的開源框架 dubbo spring cloud 未完待續 thrift 跨語言的rpc框架，facebook貢獻給apache https://thrift.apache.org/
1、restful api 2、dubbo使用xml配置 3、thrift使用IDL（interface description language 接口描述語言）文件
1 Dubbo 高可用 zookeeper宕機與dubbo直連 現象：zookeeper註冊中心宕機，還可以消費dubbo暴露的服務。 原因：dubbo服務的健壯性 （1）監控中心宕掉不影響使用，只是丟失部分採樣數據 （2）數據庫
1【windows】-安裝zookeeper 1 ) 下載zookeeper 網址 https://archive.apache.org/dist/zookeeper/zookeeper-3.4.13/ 2 ) 解壓zookeep
接上篇《Dubbo技術知識總結之四——Dubbo集羣容錯》 五. 遠程調用 上篇《Dubbo技術知識總結之四——Dubbo集羣容錯》的七個步驟中，前四個步驟是 Cluster 層的工作。遠程調用是後續步驟 5, 6, 7 的內
我們經常會需要啓動多個實例的情況來測試註冊中心、配置中心等基礎設施的高可用，也會用來測試客戶端負載均衡的調用等。但是，我們一個應用只能有一個端口號，這就使得在本機測試的時候，不得不爲同一個服務設置不同的端口來進行啓動。 在本地用不同端口啓動
目前已經達到金九銀十的階段，相信有不少程序員蠢蠢欲動，開始出去試試水，想要跳槽漲薪了！有一個朋友就想改變現狀，於是找了大量網上的面試題，強行記下之後，開始出去“試水”。 他試水之後回來和我聊天，他目前是在一家傳統企業做後端Java開發的，有
本文是 Choerodon 豬齒魚微服務系列文章的第二篇。在《Choerodon的微服務之路(一)：如何邁出關鍵的第一步》中，我們瞭解到在微服務架構中，一個完整的單體應用被拆分成多個有着獨立部署能力的業務服務，每個服務可以使用不同的編程語言
1、單體應用的缺點 1）部署效率低下 2）協作開發成本高 3）系統高可用性能差 4）線上發佈變慢 2、微服務的簡單介紹 2.1）將一個單一應用程序，按照業務拆分呢爲一組小型服務. 2.2）每個服務只做一件事，每個服務運行在自己的進程中 2.
Spring cloud配置中心 用於集中配置數據管理，簡化微服務集羣環境下大量配置的更新工作。 1:理解bootstrap.yaml 它會在application之前加載，如果和application有同名屬性，先啓動的會被覆
@[toc] Spring cloud 使用 Ribbon 來實現客戶端負載均衡 前言 在Spring cloud 中當統一類型多個服務開始註冊到服務註冊中心中，次數服務即是集羣 消費端（客戶端）消費的時候需要進行選擇調用服務。 服務註冊
Spring cloud eureka 高可用集羣配置 前言 eureka 註冊中心單機模式，容災性低，註冊服務多，單個節點性能低，容易發生故障，甚至崩潰等。 生產中我採用集羣模式，也就是eureka的高可用。 如何搭建高可用集羣配置 僅僅
Spring cloud中使用 Hystrix 前言 Hystrix 在Spring Cloud中使用了Netflix開發的Hystrix來實現熔斷器。可以稍微通過幾個簡單的代碼示例，學習Hystrix 導入依賴 <!-- 整合hy
本篇主要介紹對於微服務的理解 現如今，隨着互聯網的發展，對於系統性能，架構均有了更高的要求。以前傳統的ssh時代的單體應用的機構模式已顯力不從心，所以微服務架構應運而生，並且形成了越來越成熟的方案。寫本系列文章的目標是從單體架構模式到微服
