【從零搭建後端基礎設施系列（十）】-- 服務發現與治理（中）

原創

_acme_

2020-02-22 01:52

==> 學習彙總（持續更新）
==> 從零搭建後端基礎設施系列（一）-- 背景介紹 

沒有看過上篇的點這裏【從零搭建後端基礎設施系列（十）】-- 服務發現與治理（上）

CODE
- RegistCenter -> master
- ServiceGovernance -> master
- Min-system-thrift-service -> feature/iterate1
- Min-system-web-service -> feature/iterate1
效果演示
- 啓動註冊中心，並將三個服務註冊到註冊中心
  註冊服務
- 啓動服務治理
  啓動服務
- 啓動最小系統thrift服務
- 啓動最小系統web服務
- 再來看看服務治理的日誌
  已經有兩個服務的機器信息上報到這裏了。
- 接下來發送一個http請求看看
  
  接口全部通了。
- 將web服務重啓看看會發生什麼
- 將thrift服務重啓看看會發生什麼
  
  但是你會發現，web調用thrift的時候報錯了
  
  很明顯，連接失效了。
現象分析
- 爲什麼需要按照這樣的順序啓動？
  註冊中心必須先啓動，因爲它需要存儲其它服務的信息
  服務治理啓動需要依賴註冊中心，因爲後續其它服務上報機器信息的時候，需要判斷該服務是否已經註冊。
  然後到thrift服務，因爲它需要依賴前面兩者
  最後到web服務，因爲它需要依賴前面三者
- 爲什麼註冊中心不需要上報機器信息到服務治理中心？
  按道理是需要的，但是這裏怕麻煩，沒有做。（我在想，先有註冊中心還是先有服務治理中心？小糾結，，，後續看看怎麼優化）
- 如何檢測機器狀態的？
  通過客戶端定時發送心跳信息到服務治理中心。
  可能有人會問，爲什麼是客戶端主動發送心跳，而不是服務端主動檢測呢？
  其實兩種方法都可以實現，但是客戶端主動發送心跳可以減少服務端的消耗，並且實現起來簡單。
- 爲什麼重啓thrift服務後，web調用thrift接口會報錯？
  首先thrift服務重啓，那麼第一次的連接肯定失效了，其次第一版非常粗糙，重試機制都沒做。。。，所以會發生上面的情況。
- 使用註冊中心和服務治理有什麼優勢？
  從這個小demo都可以看出來優勢，首先，以前沒有RC(註冊中心簡稱)和SG(服務治理簡稱)的時候，web每次連接thrift都需要手動改一下ip（因爲每次重啓電腦後，IP都有可能會變），如果有N個客戶端要連thrift，那麼就需要改N個客戶端的代碼，非常的不靈活。有了RC和SG後，所有服務只需要記住RC和SG的IP，就能夠拿到其它服務的IP。當然了還有很多很多優勢，例如限流、熔斷、鑑權等等。
總結與改進
每次寫完一個小demo，都會去思考，還有什麼能改進的。就好比一個小公司成長爲大公司，期間的架構肯定是從最簡單的演化到最複雜的。例如，以前的網站架構都非常簡單，使用linux+mysql+apache+php，就可以很快的搭建出來，因爲一開始流量都很小，linux機器單機，mysql機器單機，還可能不是多臺機器，而是一臺機器，包乾所有！然後演化到現在，流量大了，場景也複雜了，什麼分佈式啊，集羣啊，統統幹上了。但是萬變不離其宗，先從它祖宗十八代研究起，把它翻個底朝天不是更有趣嗎？
- 通過這四個服務，發現thrift的代碼非常的重複
  例如服務啓動的代碼，基本每個服務都有一個ThriftServerBean，並且都幹着同樣一件事。所以，第一想法，抽出來！
```
@Component
public class ThriftServerBean implements FactoryBean<ThriftServerBean>, InitializingBean {

    private TServer tServer;
    @Value("${local.port}")
    private Integer port;
    @Value("${local.appKey}")
    private String appKey;
    @Autowired
    private TRegistCenterImpl tRegistCenter;

    @Override
    public ThriftServerBean getObject() throws Exception {
        return new ThriftServerBean();
    }

    @Override
    public Class<?> getObjectType() {
        return ThriftServerBean.class;
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        TProcessor tProcessor = new TRegistCenter.Processor<TRegistCenter.Iface>(tRegistCenter);

        TNonblockingServerSocket serverTransport = new TNonblockingServerSocket(port);

        TProtocolFactory protocolFactory = new TBinaryProtocol.Factory();

        TNonblockingServer.Args tArgs = new TNonblockingServer.Args(serverTransport);

        tArgs.processor(tProcessor);
        tArgs.protocolFactory(protocolFactory);

        tServer = new TNonblockingServer(tArgs);
        System.out.println("[info] RegistCenter bootup successful -> " + NetWorkUtil.getInet4Address() + ":" + port);
        new Thread(()-> tServer.serve()).start();
    }
}
```
  再有就是ThriftClientConfig，也是極爲重複，抽出來！
  
  所以，很有必要對thrift進行封裝，基於我們的demo（業務），進行二次開發
- 都可以將什麼抽出來呢？
  首先，我們要明白一件事，基礎設施是爲了減輕業務負擔而存在的，所以目標肯定是，thrift服務和web服務就只幹一件事，實現自己的業務邏輯，不需要管什麼連接啊，註冊啊，服務如何如何啓動啊等等。
  那麼誰來做呢？那肯定就是通信層做了，例如A調用B的接口的時候，發生了一次遠程調用，也就是網絡調用，那麼我們是不是可以用AOP，在A調B接口的前後做一些事情呢？所以又用到了spring的知識。
- 最後總結一下服務發現與治理（下）需要做的事情
  - 基於thrift進行二次開發，目標是讓每個服務專注於業務邏輯，而不需要管通信層的事情（下篇文章就乾貨滿滿哦，就不是demo級別的了）。