單體架構

簡單介紹一下四個模塊分別的作用：

• 城市信息模塊：

  主要是調用第三方服務獲取所有的城市信息，用於數據采集的時候調用

• 數據采集模塊：

  由於是基於調用第三方 api 的服務，所以我們要考慮到服務的可用性：比如網絡的原因，網絡因素的不可控的，每次調用都都可能出現各種網絡的問題：網絡連接超時、甚至連接不上，延遲太大等。所以我們應該避免多次的遠程網絡的服務調用。同時是基於第三方服務，可能有服務調用次數限制等原因，結合我們項目的需求，可以將數據定時采集緩存起來。因為天氣信息在一段時間內是變化不大。所以我們采用定時任務的形式，每30分鐘將城市信息對應的天氣信息緩存起來。

  還有這裏，根本不需要存儲太多的額外數據，最多就是一個城市數據，基於城市數據動態變化的可能性太小，我們采取 xml

  的形式存儲即可。最後基於 javax.xml.* 包下解析即可。方便快捷。減少數據庫的維護成本。

  所以，一切的技術選型都是基於業務需求去考慮的，當然前提是你得會這門技術，要不只能退而求其次。

• 天氣數據模塊：

  主要是獲取天氣數據信息。根據城市的 id 或者 城市的名字 從緩存中獲取數據信息。

• 天氣預報模塊：

  響應對應城市的最近一周天氣信息。

總而言之，整個系統不是很大，就四個模塊，每個模塊的功能也不是很多。但是每個模塊有分工明確。所以比較適合進行初級的服務劃分學習。

那什麽是單體架構呢？

其實簡單的可以理解為，單體架構就是從開發到部署，所以開發人員都是針對一個項目進行開發，最後基於這個項目部署到服務器上的。簡單來說就是所以功能都集中在一個項目中進行開發部署。而我們上面的天氣預報項目就是一個單體的架構。

這種架構也是有很多優點的，因為，我們都是這麽過來的。所以他很簡單。

那從幾個方面來體現他的簡單呢？

• 學習簡單：容易學習，上手簡單。畢竟我們都是這麽過來的。

• 部署簡單：直接一個 war 包，部署到 tomcat 中即可。

• 層次簡單：就是 dao -> service -> web 這樣開發即可。

• 技術簡單：也不能說是技術簡單吧，應該說是技術單一。spring、Mybatis就可以基本搞定。

  等等。

那說完它的優點，它的缺點呢？其實它的缺點是針對於中大型的互聯網項目來說的。由於中大型互聯網項目的特點：項目業務復雜、開發人員眾多、項目叠代周期短。基於這些特點，我們很容易就能從單體架構中發現其不足。但是要記住一點就是，不是一說大型互聯網項目就是高並發、高可用這些看起來高大上但是其實但臃腫的詞語來概括。不要高並發、高可用中毒。一切都是根據項目的情況出發。所以說，我們所謂的單體應用它的缺點是在一個項目業務復雜、開發人員眾多、項目叠代周期短的情況下才體現出來的。但是單體應用還是最基礎的。如果你堅持到最後，你會發現最後還是會回歸到類單體應用上來。那就是單元化架構（SET架構）。

好了，嗶嗶了這麽多，我們回歸正題，來說說單體架構的缺點。

• 代碼維護困難：所有人都是基於一個項目在進行開發，可能會出現代碼沖突等情況。更重要的是，代碼的安全性不高。可想而知。我們要基於單體架構開發，我們就能拿到所有代碼，這在大型互聯網公司中是不可想象的。實際上，我們只需拿到我們負責的那個模塊的代碼即可。或者與該模塊關聯的代碼。其他代碼我們都是沒有的。這也有利保護公司的利益。

• 項目叠代困難：現在的互聯網項目，更新叠代太快，三天一個小版本，一周一個大版本，也是很正常。這麽頻繁的叠代周期在單體架構中是不可能實現的。因為我們版本叠代不可能像單體架構那樣把整個項目下線更新之後再重新上線。這樣三天兩頭上下線，切合實際嗎？顯然是不可能的。

• 復雜的業務需求應對有些吃力：現在很多互聯網公司都是有很多相關的項目的。比如百度的百度文檔、百度網盤、百度知道。。。等等。業務形式多種多樣。如果在一個單體的架構中代碼太過龐大。這個是難以想象的。

  最後在補充幾點：交付周期長、可伸縮性差、監控困難、等。

分布式架構的演進概要

基於單體架構上面的缺點，我們需要對項目的架構進行改進，來增加項目的穩定性和可擴展性等。如何一個人買菜、煮飯、炒菜。全家人吃飯，憑什麽我一個買菜、煮飯、炒菜啊！所以我們多個人來，你買菜、我煮飯、他炒菜。快捷簡單又不累。項目也是這樣，像單體架構那樣，服務器太累！所以請求都是它一個人扛，一個人處理。我已得將項目拆分開來。分別部署在多臺服務器上。這就是分布式架構。

分布式與集群

集群與分布式是息息相關的，因為他們都是為了達到高可用的目的。

那什麽是集群呢？

簡單理解，就是洗碗那樣。比如大過年，親朋好友來得特別多，吃完飯，碗筷也就是多咯，那一個人來洗的，太累，那就多個人來洗不就行了嗎。

這就是集群的概念：多個人，幹同一件事。也就是說，多臺服務器，每臺服務器處理的業務都是一樣的。而分布式，多個人分開來，來完成一件事。

分布式架構的項目是如何拆分的呢？

項目拆分是分布式架構最重要的一環。當然，也不可能一下子就能拆分得很完美，這些都是與你的項目經驗、業務能力息息相關的。我們只能做到盡可能的準，盡可能接近完美。

那我們怎麽去拆分呢?

業界早已有許多大牛總結了很多經驗，我們可以參考學習，指導我們。最後結合我們的業務需求進行項目拆分。

比如項目拆分的時候需要考慮哪些問題？需要遵循哪些原則？需要註意哪些點？這些我們都能從大牛哪裏吸收經驗。

由於我們的項目業務比較簡單，很多拆分的規則都體現不出來，如下圖

? 註：每個白色的框框都是一個項目，單獨部署在一臺服務器上的項目，然後又有集群。其實應用層也是可以集群的。比如：

所以從上面的圖中我們可以簡單的了解了一下什麽是分布式的架構。那同樣也面面臨著許多問題。

比如：分布式session、不同項目之間如何通信、集群中數據一致性、分布式安全、事務、負載均衡等。很多問題。這些問題現在已經有了很好的解決方案。我們這裏不再贅述。我們主要是講springcloud實現的微服務。這裏只是簡單了解一下分布式，和分布式架構的基礎模型。

微服務架構

如果說什麽是微服務？我們只能理解為是這樣的，微服務是粒度更小的分布式，但它還是分布式。

上面這一點很重要，有人會以為，微服務是一種全新的架構，比分布式更吊的架構，其實不然，只是對比於傳統的分布式架構粒度更小。這是我個人的理解。

下面我們談談幾個簡單、但是又很重要的概念：

• SOA： Service - Oriented - Architecture 面向服務的體系架構

  你可以簡單理解為它是一種規範，架構設計的指導思想。就像馬克思主義指導我們天天向上。是一個好的開發指導原則。

  主要包括以下幾個原則：

  • 服務的契約

  • 服務的可組合性

  • 服務的無狀態

  • 服務的可被發現

  • 服務自治

    等原則。

    簡單理解就是，能夠對外提供特定的服務，每個消費該服務的消費者對於該服務是透明的，消費者只需調用服務即可，不需要關心服務內部的運轉。同時該服務可以調用其他基礎的服務組成。

    上面只是簡單理解，在我個人理解的程度更加白話的方式書寫，所以在這裏只需了解這是什麽就可以

  • 下面我們講講實現SOA的幾種常見但是有古老的存在：註意下面也是一種規範，只不過是根據SOA設計出來的

    • REST： 表現層轉態轉換 Representational State Transfer 是 Roy Thomas Fielding 博士在他的博士論文中提出來的。在2000年的時候就提出來啦。是一種URL設計風格。現在很流行的一種設計風格，雅虎和亞馬遜等都有使用。
    • SOAP ：簡單對象訪問協議。是一種基於http + xml 的通訊協議。而REST是基於http+json

  好，我們就將這些比較常見的概念講到這裏，如果你還想了解JMI、EJB等。可以自行找資料學習。

  但是請註意SOA不是微服務，它跟微服務還是有很大的區別的。

-- 這個先講到這裏。。

基於天氣預報項目談springcloud構建的微服務（一）