wordpress rest api，平臺組件是什么？
平臺組件包含以下內容:1.Mysql
傳統關系型數據庫，為Hive、Hue、Spark組件提供元數據存儲服務。
2.Elasticsearch
兼有搜索引擎和NoSQL數據庫功能的開源系統，基于JAVA/Lucene構建，開源、分布式、支持RESTful請求。
3.Flink
一個批處理和流處理結合的統一計算框架，提供數據分發以及并行化計算的流數據處理引擎。
4.Flume
一個分布式、可靠和高可用的海量日志聚合系統，支持在系統中定制各類數據發送方，用于收集數據；
同時，Flume提供對數據進行簡單處理，并寫入各種數據接受方(可定制)的能力。
5.HBase
提供海量數據存儲功能，是一種構建在HDFS之上的分布式、面向列的存儲系統。HDFS Hadoop分布式文件系統提供高吞吐量的數據訪問，適合大規模數據集方面的應用。
6.Hive
建立在Hadoop基礎上的開源的數據倉庫，提供類似SQL的Hive Query Language語言操作結構化數據存儲服務和基本的數據分析服務。
7.Hue
提供了圖形化用戶Web界面。Hue支持展示多種組件，目前支持HDFS、Hive、YARN/Mapreduce、Oozie、Solr、ZooKeeper。
8.Kafka
一個分布式的、分區的、多副本的實時消息發布和訂閱系統。提供可擴展、高吞吐、低延遲、高可靠的消息分發服務。
9.Sqoop
實現與關系型數據庫、文件系統之間交換數據和文件的數據加載工具；同時提供REST API接口，供第三方調度平臺調用。
10.Mapreduce
提供快速并行處理大量數據的能力，是一種分布式數據處理模式和執行環境。
11.Oozie
提供了對開源Hadoop組件的任務編排、執行的功能。以Java Web應用程序的形式運行在Java servlet容器(如：Tomcat)中，并使用數據庫來存儲工作流定義、當前運行的工作流實例(含實例的狀態和變量)。
12.Redis 一個開源的、高性能的key-value分布式存儲數據庫，支持豐富的數據類型，彌補了memcached這類key-value存儲的不足，滿足實時的高并發需求。
13.SmallFS
提供小文件后臺合并功能，能夠自動發現系統中的小文件(通過文件大小閾值判斷)，在閑時進行合并，并把元數據存儲到本地的LevelDB中，來降低NameNode壓力，同時提供新的FileSystem接口，讓用戶能夠透明的對這些小文件進行訪問。
14.Solr
一個高性能，基于Lucene的全文檢索服務器。Spark 基于內存進行計算的分布式計算框架。
15.Storm
提供分布式、高性能、高可靠、容錯的實時計算平臺，可以對海量數據進行實時處理。CQL提供的類SQL流處理語言，可以快速進行業務開發，縮短業務上線時間。
16.Yarn
資源管理系統，它是一個通用的資源模塊，可以為各類應用程序進行資源管理和調度。
17.ZooKeeper
提供分布式、高可用性的協調服務能力。幫助系統避免單點故障，從而建立可靠的應用程序。
企業設備如何實現信息化管理？
每個公司都有各種各樣的設備，但關于設備管理總有很多的問題：如何將這么多設備有條理地管理起來？如何記錄設備的生命周期？如何建立設備檔案？下面告訴你如何用簡道云解決設備管理難題。
第一步：統計本公司所有設備，建立一張excel表格（如下圖所示）：第二步：將統計好的Excel表格導入簡道云中：第三步：通過簡道云數據鏈接功能，批量打印設備二維碼。秉承“一物一碼”的原則，確保每臺設備對應一個二維碼。
第四步：將打印出來的二維碼一一張貼到各個設備上通過同步釘釘／企業微信通訊錄將數據權限共享給團隊成員，成員使用釘釘/企業微信“掃一掃”功能掃碼，即可查看對應設備的所有信息。
當然，只是查看信息顯然不能完全滿足公司設備管理需求，除了在設備信息里嵌入設備照片、設備安全操作規程、GPS地圖定位等，操作人員還能在線實時添加設備最新巡檢信息。（掃碼后跳出下圖所示信息表）設備發生故障時如需報修：巡檢員可在線發送報修申請，通過簡道云的流程、智能提醒功能，維修人員將實時在線收到維修申請，并查看需要維修的設備信息，拒絕一切非不可抗因素導致的工作進展遲滯！
控制數據權限、保障信息安全：不同職能部門管理不同設備（或同一臺設備的不同部分），通過簡道云的權限功能，對員工的操作和查看權限進行設置：
數據匯總和分析：為使管理者掌握一線工作情況，所有巡檢維修記錄均可實時匯總，并自動生成報表和統計圖，也可導出到Excel，滿足企業信息化管理要求。
通過以上的解決方案，小到打印機、復印機、飲水機、大樓空調電梯的管理，大到電力、鐵路、水利設備巡檢，都可以通過簡道云實現。以上，希望能幫到你哦~restful優缺點？
寫一下我對restful的理解，最近換工作面試的時候有問到我restful api的東西，工作中以前很多項目也是webapi + js前臺控件的形式構建系統。實際上感覺restful太“理想化”,用起來不是特別順手, 舉例說明下：
先看看什么叫restful：
REST的名稱"表現層狀態轉化"中，省略了主語。"表現層"其實指的是"資源"（Resources）的"表現層"。
所謂"資源"，就是網絡上的一個實體，或者說是網絡上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。你可以用一個URI（統一資源定位符）指向它，每種資源對應一個特定的URI。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨一無二的識別符。
客戶端用到的手段，只能是HTTP協議。具體來說，就是HTTP協議里面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用于更新資源），PUT用來更新資源，DELETE用來刪除資源。
GET /tickets # 獲取ticket列表
GET /tickets/12 # 查看某個具體的ticket
POST /tickets # 新建一個ticket
PUT /tickets/12 # 更新ticket 12.
DELETE /tickets/12 #刪除ticekt 12
實際上呢，不是所有的東西都是“資源”，尤其是在業務系統中，缺點如下：
有個接口是更新訂單狀態，你是用上面的GET POST PUT DELETE 哪個呢，看樣子應該是PUT，但是路徑呢PUT /tickets/12
我有時候多個接口 ，更新訂單收款狀態，更新訂單支款狀態，更新訂單結算狀態；
Restful 的路徑明顯不友好不夠用；
比如，Resuful要求 GET /tickets # 獲取ticket列表 。我們曾經有個需求，對方會把不超過1000個訂單id傳給我們，我們系統過濾其中一部分特殊訂單；這也是個查詢服務，用GET /tickets # 獲取ticket列表的形式，1000個訂單id顯然是超過GET url長度的，這里也不合適；再者，我想開發多個條件查詢列表服務，路徑這么淺顯然不合適；
實際業務中，我們webapi的路徑是這樣的：systemAlias/controller/action
總結下規則：
簡單查詢盡量用GET，好處是可以直接帶查詢參數copy api路徑；
復雜查詢和更新用POST，用的最多；
不用PUT和DELETE，原因是增加復雜度，并沒有帶來什么好處
看看BAT的很多openapi，也是寫著restful，實際沒有嚴格遵守，都是get和post，這是也很多人不知道put和delete的原因
wordpress文章歸檔archivephp和分類目錄模板categoryphp的區別是什么？
archive.php是調用你網站的所以分類目錄 category.php是調用某一個id的分類目錄。 這兩個文件可以調用不同的樣式模板
軟件產品架構中什么是單體架構SOA架構微服務架構？
軟件架構的發展經歷了從單體架構、垂直架構、SOA架構到微服務架構的過程。
單體架構Web應用程序發展的早期，大部分web工程師將所有的功能模塊打包到一起并放在一個web容器中運行，所有功能模塊使用同一個數據庫。下圖是一個單體架構的電商系統：特點：1、所有的功能集成在一個項目工程中。2、所有的功能打在一個war包部署到服務器。3、通過部署應用集群和數據庫集群來提高系統的性能。優點：1、項目架構簡單，前期開發成本低，周期短，小型項目的首選。2、開發效率高，模塊之間交互采用本地方法調用。3、容易部署，運維成本小，直接打包為一個完整的包，拷貝到web容器的某個目錄下即可運行。4、容易測試：IDE都是為開發單個應用設計的、容易測試——在本地就可以啟動完整的系統。缺點：1、全部功能集成在一個工程中，對于大型項目不易開發、擴展及維護。2、版本迭代速度逐漸變慢，修改一個地方就要將整個應用全部編譯、部署、啟動，開發及測試周期過長。3、無法按需伸縮，通過集群的方式來實現水平擴展，無法針對某業務按需伸縮。分布式架構 針對單體架構的不足，為了適應大型項目的開發需求，許多公司將一個單體系統按業務垂直拆分為若干系統，系統之間通過網絡交互來完成用戶的業務處理，每個系統可分布式部署，這種架構稱為分布式架構。特點：1、按業務垂直拆分成一個一個的單體系統，此架構也稱為垂直架構。2、系統與系統之間的存在數據冗余，耦合性較大，如上圖中三個項目都存在客戶信息。3、系統之間的接口多為實現數據同步，如上圖中三個項目要同步客戶信息。優點：1、通過垂直拆分，每個子系統變成小型系統，功能簡單，前期開發成本低，周期短。2、每個子系統可按需伸縮。3、每個子系統可采用不同的技術。缺點：1、子系統之間存在數據冗余、功能冗余，耦合性高。2、按需伸縮粒度不夠，對同一個子系統中的不同的業務無法實現，比如訂單管理和用戶管理。SOA架構 SOA是一種面向服務的架構，基于分布式架構，它將不同業務功能按服務進行拆分，并通過這些服務之間定義良好的接口和協議聯系起來。特點：1、基于SOA的架構思想，將重復公用的功能抽取為組件，以服務的方式向各各系統提供服務。 2、各各系統與服務之間采用webservice、rpc等方式進行通信。3、ESB企業服務總線作為系統與服務之間通信的橋梁。優點：1、將重復的功能抽取為服務，提高開發效率，提高系統的可重用性、可維護性。2、可以針對不同服務的特點按需伸縮。3、采用ESB減少系統中的接口耦合。缺點：1、系統與服務的界限模糊，會導致抽取的服務的粒度過大，系統與服務之間耦合性高。2、雖然使用了ESB，但是服務的接口協議不固定，種類繁多，不利于系統維護。微服務架構 基于SOA架構的思想，為了滿足移動互聯網對大型項目及多客戶端的需求，對服務層進行細粒度的拆分，所拆分的每個服務只完成某個特定的業務功能，比如訂單服務只實現訂單相關的業務，用戶服務實現用戶管理相關的業務等等，服務的粒度很小，所以稱為微服務架構。特點：1、服務層按業務拆分為一個一個的微服務。2、微服務的職責單一。3、微服務之間采用RESTful、RPC等輕量級協議傳輸。4、有利于采用前后端分離架構。優點：1、服務拆分粒度更細，有利于資源重復利用，提高開發效率。2、可以更加精準的制定每個服務的優化方案，按需伸縮。3、適用于互聯網時代，產品迭代周期更短。缺點：1、開發的復雜性增加，因為一個業務流程需要多個微服務通過網絡交互來完成。2、微服務過多，服務治理成本高，不利于系統維護。