海外網8月5日電 據韓聯社報道，南韓雇傭勞動部5日在官報釋出公告，宣布2021年最低時薪定為8720韓元（約合人民币51元）。此次最低時薪同比上調1.5%，漲幅為曆史新低。
新标準将從2021年1月1日起生效。如果按每周工時40小時計算，明年最低月薪為182.248萬韓元（約合人民币10665元）。各企事業機關将不分行業适用新标準。
根據南韓《最低工資法》，勞資雙方可到7月30日前就最低時薪提出異議，但沒有一個團體提出異議。勞動界對明年最低時薪表示反對，但沒有提出異議，隻要求推動最低工資制度整體改革。
看到這個想問，中國啥時候調啊……
Dubbo的核心功能？
主要就是如下3個核心功能：
§ Remoting：網絡通信架構，提供對多種NIO架構抽象封裝，包括“同步轉異步”和“請求-響應”模式的資訊交換方式。
§ Cluster：服務架構，提供基于接口方法的透明遠端過程調用，包括多協定支援，以及軟負載均衡，失敗容錯，位址路由，動态配置等叢集支援。
§ Registry：服務注冊，基于注冊中心目錄服務，使服務消費方能動态的查找服務提供方，使位址透明，使服務提供方可以平滑增加或減少機器。
Dubbo支援哪些協定，每種協定的應用場景，優缺點？
· dubbo： 單一長連接配接和NIO異步通訊，适合大并發小資料量的服務調用，以及消費者遠大于提供者。傳輸協定TCP，異步，Hessian序列化；
· rmi： 采用JDK标準的rmi協定實作，傳輸參數和傳回參數對象需要實作Serializable接口，使用java标準序列化機制，使用阻塞式短連接配接，傳輸資料包大小混合，消費者和提供者個數差不多，可傳檔案，傳輸協定TCP。多個短連接配接，TCP協定傳輸，同步傳輸，适用正常的遠端服務調用和rmi互操作。在依賴低版本的Common-Collections包，java序列化存在安全漏洞；
· webservice： 基于WebService的遠端調用協定，內建CXF實作，提供和原生WebService的互操作。多個短連接配接，基于HTTP傳輸，同步傳輸，适用系統內建和跨語言調用；
· http： 基于Http表單送出的遠端調用協定，使用Spring的HttpInvoke實作。多個短連接配接，傳輸協定HTTP，傳入參數大小混合，提供者個數多于消費者，需要給應用程式和浏覽器JS調用；
· hessian： 內建Hessian服務，基于HTTP通訊，采用Servlet暴露服務，Dubbo内嵌Jetty作為伺服器時預設實作，提供與Hession服務互操作。多個短連接配接，同步HTTP傳輸，Hessian序列化，傳入參數較大，提供者大于消費者，提供者壓力較大，可傳檔案；
· memcache： 基于memcached實作的RPC協定
· redis： 基于redis實作的RPC協定
Dubbo逾時時間怎樣設定？
Dubbo逾時時間設定有兩種方式：
· 服務提供者端設定逾時時間，在Dubbo的使用者文檔中，推薦如果能在服務端多配置就盡量多配置，因為服務提供者比消費者更清楚自己提供的服務特性。
· 服務消費者端設定逾時時間，如果在消費者端設定了逾時時間，以消費者端為主，即優先級更高。因為服務調用方設定逾時時間控制性更靈活。如果消費方逾時，服務端線程不會定制，會産生警告。
Dubbo總體架構
Dubbo的總體架構，如圖所示：
Dubbo架構圖注釋：
圖中左邊淡藍背景的為服務消費方使用的接口；
右邊淡綠色背景的為服務提供方使用的接口；
位于中軸線上的為雙方都用到的接口；
最上面的Service層是留給實際想要使用Dubbo開發分布式服務的開發者實作業務邏輯的接口層。
Dubbo架構設計一共劃分了10個層：
服務接口層（Service）
該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實作。
配置層（Config）
對外配置接口，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類，也可以通過spring解析配置生成配置類。
服務代理層（Proxy）
服務接口透明代理，生成服務的用戶端Stub和伺服器端Skeleton，以ServiceProxy為中心，擴充接口為ProxyFactory。
服務注冊層（Registry）
封裝服務位址的注冊與發現，以服務URL為中心，擴充接口為RegistryFactory、Registry和RegistryService。可能沒有服務注冊中心，此時服務提供方直接暴露服務。
叢集層（Cluster）
封裝多個提供者的路由及負載均衡，并橋接注冊中心，以Invoker為中心，擴充接口為Cluster、Directory、Router和LoadBalance。将多個服務提供方組合為一個服務提供方，實作對服務消費方來透明，隻需要與一個服務提供方進行互動。
監控層（Monitor）
RPC調用次數和調用時間監控，以Statistics為中心，擴充接口為MonitorFactory、Monitor和MonitorService。
遠端調用層（Protocol）
封裝RPC調用，以Invocation和Result為中心，擴充接口為Protocol、Invoker和Exporter。Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命周期管理。Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠攏，或轉換成它，它代表一個可執行體，可向它發起invoke調用，它有可能是一個本地的實作，也可能是一個遠端的實作，也可能一個叢集實作。
資訊交換層（Exchange）
封裝請求響應模式，同步轉異步，以Request和Response為中心，擴充接口為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
網絡傳輸層（Transport）
抽象mina和netty為統一接口，以Message為中心，擴充接口為Channel、Transporter、Client、Server和Codec。
資料序列化層（Serialize）
可複用的一些工具，擴充接口為Serialization、 ObjectInput、ObjectOutput和ThreadPool。
Dubbo的使用場景
1.RPC分布式服務
當網站變大後，不可避免的需要拆分應用進行服務化，以提高開發效率，調優性能，節省關鍵競争資源等。
比如：為了适用不斷變化的市場需求，以及多個垂直應用之間資料互動友善，我們把公共的業務抽取出來作為獨立的子產品，為其他的應用提供服務，系統逐漸依賴于抽象和rpc遠端服務調用。
2.配置管理
當服務越來越多時，服務的URL位址資訊就會爆炸式增長，配置管理變得非常困難，F5硬體負載均衡器的單點壓力也越來越大。
3.服務依賴
當進一步發展，服務間依賴關系變得錯綜複雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關系。
4.服務擴容
接着，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？等等……