摘要: from:http://agapple.iteye.com/blog/1005918背景    周五下班回家,在公司班車上覺得無聊,看了下btrace的源碼(自己反編譯)。 一些關于btrace的基本內容,可以看下我早起的一篇記錄:btrace記憶    上一篇主要介紹的是btrace的一些基本使用以及api,這里我想從btrace源碼本...  閱讀全文
          posted @ 2015-12-18 18:08 小馬歌 閱讀(385) | 評論 (0)編輯 收藏
           

          很多時候在online的應用出現問題時,很多時候我們需要知道更多的程序的運行細節,但又不可能在開發的時候就把程序中所有的運行細節都打印到日志上,通常這個時候能采取的就是修改代碼,重新部署,然后再觀察,但這種方法對于online應用來說不是很好,另外一方面如果碰到不好改的代碼,例如引用的其他的外部的包什么的,就很麻煩了,BTrace就是一個可以在不改代碼、不重啟應用的情況下,動態的查看程序運行細節的工具,其官方網站在此:http://kenai.com/projects/btrace/ ,在這篇blog中,就來看看如何用BTrace來動態的監測方法的一些運行細節狀況。
          BTrace通過動態的掛接用java寫的代碼到運行時上來獲取到一些運行細節,例如典型的使用btrace的方法為:
          btrace -cp [btrace的jar所在的路徑,默認為btrace/build下] [pid] [需要運行的java代碼]
          例如一段這樣的代碼:
          [java]
          import java.util.Random;
          public class Case1{

          public static void main(String[] args) throws Exception{
          Random random=new Random();
          CaseObject object=new CaseObject();
          boolean result=true;
          while(result){
          result=object.execute(random.nextInt(1000));
          Thread.sleep(1000);
          }
          }

          }
          public class CaseObject{

          private static int sleepTotalTime=0;

          public boolean execute(int sleepTime) throws Exception{
          System.out.println("sleep: "+sleepTime);
          sleepTotalTime+=sleepTime;
          Thread.sleep(sleepTime);
          return true;
          }

          }
          [/java]
          如在程序運行的情況下,想知道調用CaseObject的execute方法的以下幾種情況,在BTrace中可以這么做:
          1、調用此方法時傳入的是什么參數,返回的是什么值,當時sleepTotalTime是多少?
          BTrace腳本如下:
          [java]
          import static com.sun.btrace.BTraceUtils.*;
          import com.sun.btrace.annotations.*;

          @BTrace public class TraceMethodArgsAndReturn{
          @OnMethod(
          clazz="CaseObject",
          method="execute",
          location=@Location(Kind.RETURN)
          )
          public static void traceExecute(@Self CaseObject instance,int sleepTime,@Return boolean result){
          println("call CaseObject.execute");
          println(strcat("sleepTime is:",str(sleepTime)));
          println(strcat("sleepTotalTime is:",str(get(field("CaseObject","sleepTotalTime"),instance))));
          println(strcat("return value is:",str(result)));
          }
          }
          [/java]
          然后直接執行btrace -cp btrace/build [pid] TraceMethodArgsAndReturn.java就可以了。
          當程序中調用到caseobject的execute方法時,就會在btrace的console中輸出相應的信息。
          2、execute方法執行耗時是多久?
          BTrace腳本如下:
          [java]
          import static com.sun.btrace.BTraceUtils.*;
          import com.sun.btrace.annotations.*;

          @BTrace public class TraceMethodExecuteTime{

          @TLS static long beginTime;

          @OnMethod(
          clazz="CaseObject",
          method="execute"
          )
          public static void traceExecuteBegin(){
          beginTime=timeMillis();
          }

          @OnMethod(
          clazz="CaseObject",
          method="execute",
          location=@Location(Kind.RETURN)
          )
          public static void traceExecute(int sleepTime,@Return boolean result){
          println(strcat(strcat("CaseObject.execute time is:",str(timeMillis()-beginTime)),"ms"));
          }
          }
          [/java]
          3、誰調用了execute方法?
          BTrace腳本如下:
          [java]
          import static com.sun.btrace.BTraceUtils.*;
          import com.sun.btrace.annotations.*;

          @BTrace public class TraceMethodCallee{
          @OnMethod(
          clazz="CaseObject",
          method="execute"
          )
          public static void traceExecute(){
          println("who call CaseObject.execute :");
          jstack();
          }
          }
          [/java]
          4、有沒有人調用CaseObject中的哪一行代碼?
          BTrace腳本如下:
          [java]
          import static com.sun.btrace.BTraceUtils.*;
          import com.sun.btrace.annotations.*;

          @BTrace public class TraceMethodLine{
          @OnMethod(
          clazz="CaseObject",
          location=@Location(value=Kind.LINE,line=5)
          )
          public static void traceExecute(@ProbeClassName String pcn,@ProbeMethodName String pmn,int line){
          println(strcat(strcat(strcat("call ",pcn),"."),pmn));
          }
          }
          [/java]
          從上面可看出,在有了BTrace后,要動態的跟蹤代碼的運行細節還是非常爽的,更多的細節的操作請大家查看BTrace的User Guide

          posted @ 2015-12-18 14:52 小馬歌 閱讀(313) | 評論 (0)編輯 收藏
           
          mvn install:install-file -Dfile=D:/spymemcached-2.10.3.jar -DgroupId=net.spy -DartifactId=spymemcached -Dversion=2.10.3 -Dpackaging=jar
          mvn install:install-file -Dfile=D:/spymemcached-2.10.3-sources.jar -DgroupId=net.spy -DartifactId=spymemcached -Dversion=2.10.3 -Dpackaging=jar -Dclassifier=sources
          mvn install:install-file -Dfile=D:/spymemcached-2.10.3-javadoc.jar -DgroupId=net.spy -DartifactId=spymemcached -Dversion=2.10.3 -Dpackaging=jar -Dclassifier=javadoc
          posted @ 2015-12-17 18:58 小馬歌 閱讀(294) | 評論 (0)編輯 收藏
           

          很榮幸,作為這樣一款業界使用率和好評率出眾的RPC框架的維護者,今天這個文章主要是想幫助那些熱愛開源的同學,更好的來研究dubbo的源代碼。

           一、Dubbo整體架構

          1、Dubbo與Spring的整合
          Dubbo在使用上可以做到非常簡單,不管是Provider還是Consumer都可以通過Spring的配置文件進行配置,配置完之后,就可以像使用spring bean一樣進行服務暴露和調用了,完全看不到dubbo api的存在。這是因為dubbo使用了spring提供的可擴展Schema自定義配置支持。在spring配置文件中,可以像、這樣進行配置。META-INF下的spring.handlers文件中指定了dubbo的xml解析類:DubboNamespaceHandler。像前面的被解析成ServiceConfig,被解析成ReferenceConfig等等。
          2、jdk spi擴展
          由于Dubbo是開源框架,必須要提供很多的可擴展點。Dubbo是通過擴展jdk spi機制來實現可擴展的。具體來說,就是在META-INF目錄下,放置文件名為接口全稱,文件中為key、value鍵值對,value為具體實現類的全類名,key為標志值。由于dubbo使用了url總線的設計,即很多參數通過URL對象來傳遞,在實際中,具體要用到哪個值,可以通過url中的參數值來指定。
          Dubbo對spi的擴展是通過ExtensionLoader來實現的,查看ExtensionLoader的源碼,可以看到Dubbo對jdk spi做了三個方面的擴展:

          (1)jdk spi僅僅通過接口類名獲取所有實現,而ExtensionLoader則通過接口類名和key值獲取一個實現;

          (2)Adaptive實現,就是生成一個代理類,這樣就可以根據實際調用時的一些參數動態決定要調用的類了。

          (3)自動包裝實現,這種實現的類一般是自動激活的,常用于包裝類,比如Protocol的兩個實現類:ProtocolFilterWrapper、ProtocolListenerWrapper。
          3、url總線設計
          Dubbo為了使得各層解耦,采用了url總線的設計。我們通常的設計會把層與層之間的交互參數做成Model,這樣層與層之間溝通成本比較大,擴展起來也比較麻煩。因此,Dubbo把各層之間的通信都采用url的形式。比如,注冊中心啟動時,參數的url為:
          registry://0.0.0.0:9090?codec=registry&transporter=netty
          這就表示當前是注冊中心,綁定到所有ip,端口是9090,解析器類型是registry,使用的底層網絡通信框架是netty。

           二、Dubbo啟動過程

          Dubbo分為注冊中心、服務提供者(provider)、服務消費者(consumer)三個部分。
          1、注冊中心啟動過程
          注冊中心的啟動過程,主要看兩個類:RegistrySynchronizer、RegistryReceiver,兩個類的初始化方法都是start。
          RegistrySynchronizer的start方法:

          (1)把所有配置信息load到內存;

          (2)把當前注冊中心信息保存到數據庫;

          (3)啟動5個定時器。
          5個定時器的功能是:
          (1)AutoRedirectTask,自動重定向定時器。默認1小時運行1次。如果當前注冊中心的連接數高于平均值的1.2倍,則將多出來的連接數重定向到其他注冊中心上,以達到注冊中心集群的連接數均衡。
          (2)DirtyCheckTask,臟數據檢查定時器。作用是:分別檢查緩存provider、數據庫provider、緩存consumer、數據庫consumer的數據,清除臟數據;清理不存活的provider和consumer數據;對于緩存中的存在的provider或consumer而數據庫不存在,重新注冊和訂閱。
          (3)ChangedClearTask,changes變更表的定時清理任務。作用是讀取changes表,清除過期數據。
          (4)AlivedCheckTask,注冊中心存活狀態定時檢查,會定時更新registries表的expire字段,用以判斷注冊中心的存活狀態。如果有新的注冊中心,發送同步消息,將當前所有注冊中心的地址通知到所有客戶端。
          (5)ChangedCheckTask,變更檢查定時器。檢查changes表的變更,檢查類型包括:參數覆蓋變更、路由變更、服務消費者變更、權重變更、負載均衡變更。
          RegistryReceiver的start方法:啟動注冊中心服務。默認使用netty框架,綁定本機的9090端口。最后啟動服務的過程是在NettyServer來完成的。接收消息時,拋開dubbo協議的解碼器,調用類的順序是

          NettyHandler-》NettyServer-》MultiMessageHandler-》HeartbeatHandler-》AllDispatcher-》 DecodeHandler-》HeaderExchangeHandler-》RegistryReceiver-》RegistryValidator-》RegistryFailover-》RegistryExecutor

          2、provider啟動過程
          provider的啟動過程是從ServiceConfig的export方法開始進行的,具體步驟是:
          (1)進行本地jvm的暴露,不開放任何端口,以提供injvm這種形式的調用,這種調用只是本地調用,不涉及進程間通信。
          (2)調用RegistryProtocol的export。
          (3)調用DubboProtocol的export,默認開啟20880端口,用以提供接收consumer的遠程調用服務。
          (4)通過新建RemoteRegistry來建立與注冊中心的連接。
          (5)將服務地址注冊到注冊中心。
          (6)去注冊中心訂閱自己的服務。
          3、consumer啟動過程
          consumer的啟動過程是通過ReferenceConfig的get方法進行的,具體步驟是:
          (1)通過新建RemoteRegistry來建立與注冊中心的連接。
          (2)新建RegistryDirectory并向注冊中心訂閱服務,RegistryDirectory用以維護注冊中心獲取的服務相關信息。
          (3)創建代理類,發起consumer遠程調用時,實際調用的是InvokerInvocationHandler。

          三、實際調用過程
          consumer端發起調用時,實際調用經過的類是:
          1、consumer:

          InvokerInvocationHandler-》MockClusterInvoker(如果配置了Mock,則直接調用本地Mock類)-》FailoverClusterInvoker(負載均衡,容錯機制,默認在發生錯誤的情況下,進行兩次重試)-》RegistryDirectory$InvokerDelegete-》ConsumerContextFilter-》FutureFilter->DubboInvoker

          2、provider:

          NettyServer-》MultiMessageHandler-》HeartbeatHandler-》AllDispatcher-》DecodeHandler-》HeaderExchangeHandler-》DubboProtocol.requestHandler-》EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》TimeoutFilter-》MonitorFilter-》TraceFilter-》實際service

          四、Dubbo使用的設計模式
          1、工廠模式
          ServiceConfig中有個字段,代碼是這樣的:

          private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

          Dubbo里有很多這種代碼。這也是一種工廠模式,只是實現類的獲取采用了jdk spi的機制。這么實現的優點是可擴展性強,想要擴展實現,只需要在classpath下增加個文件就可以了,代碼零侵入。另外,像上面的Adaptive實現,可以做到調用時動態決定調用哪個實現,但是由于這種實現采用了動態代理,會造成代碼調試比較麻煩,需要分析出實際調用的實現類。
          2、裝飾器模式
          Dubbo在啟動和調用階段都大量使用了裝飾器模式。以Provider提供的調用鏈為例,具體的調用鏈代碼是在ProtocolFilterWrapper的buildInvokerChain完成的,具體是將注解中含有group=provider的Filter實現,按照order排序,最后的調用順序是

          EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》 TimeoutFilter-》MonitorFilter-》TraceFilter

          更確切地說,這里是裝飾器和責任鏈模式的混合使用。例如,EchoFilter的作用是判斷是否是回聲測試請求,是的話直接返回內容,這是一種責任鏈的體現。而像ClassLoaderFilter則只是在主功能上添加了功能,更改當前線程的ClassLoader,這是典型的裝飾器模式。
          3、觀察者模式
          Dubbo的provider啟動時,需要與注冊中心交互,先注冊自己的服務,再訂閱自己的服務,訂閱時,采用了觀察者模式,開啟一個listener。注冊中心會每5秒定時檢查是否有服務更新,如果有更新,向該服務的提供者發送一個notify消息,provider接受到notify消息后,即運行NotifyListener的notify方法,執行監聽器方法。
          4、動態代理模式
          Dubbo擴展jdk spi的類ExtensionLoader的Adaptive實現是典型的動態代理實現。Dubbo需要靈活地控制實現類,即在調用階段動態地根據參數決定調用哪個實現類,所以采用先生成代理類的方法,能夠做到靈活的調用。生成代理類的代碼是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理類的主要邏輯是,獲取URL參數中指定參數的值作為獲取實現類的key。

           

          posted @ 2015-12-15 19:25 小馬歌 閱讀(233) | 評論 (0)編輯 收藏
           
          摘要:Google于2004年公布了MapReduce論文,為數據領域工作者開啟了大數據算法之門。然而Google的大數據腳步顯然不止于此,其后公布了Percolator、Pregel、Dremel、Spanner等多篇論文。沒有止步的不僅是Google,很多公司也跟隨其腳步開發了很多優秀的產品,雖然其中不乏模仿。

          Mikio L. Braun柏林工業大學機器學習學博士后,TWIMPACT聯合創始人兼首席數據科學家。在其個人博客上總結了Google近幾年大數據領域的論文,并發表了自己的見解。

          以下為譯文:

          主流的大數據基本都是MapReduce的衍生,然而把目光聚焦到實時上就會發現:MapReuce的局限性已經漸漸浮現。下面將討論一下自大數據開始,Google公布的大數據相關技術,以及這些技術的現狀。

          MapReuce、Google File System以及Bigtable:大數據算法的起源

          按時間算第一篇的論文應該2003年公布的 Google File System,這是一個分布式文件系統。從根本上說:文件被分割成很多塊,使用冗余的方式儲存于商用機器集群上;這里不得不說基本上Google每篇論文都是關于“商用機型”。

          緊隨其后的就是2004年被公布的 MapReduce,而今MapReuce基本上已經代表了大數據。傳說中,Google使用它計算他們的搜索索引。而Mikio L. Braun認為其工作模式應該是:Google把所有抓取的頁面都放置于他們的集群上,并且每天都使用MapReduce來重算。

          Bigtable發布于2006年,啟發了無數的NoSQL數據庫,比如:Cassandra、HBase等等。Cassandra架構中有一半是模仿Bigtable,包括了數據模型、SSTables以及提前寫日志(另一半是模仿Amazon的Dynamo數據庫,使用點對點集群模式)。

          Percolator:處理個體修改

          Google并沒有止步于MapReduce。事實上,隨著Internet的指數增長,從零開始重算所有搜索索引變得不切實際。取而代之,Google開發了一個更有價值的系統,同樣支持分布式計算。

          這也是其有趣的地方,特別是在對比常見的主流大數據之后。舉個例子,Percolator引入了事務,而一些NoSQL數據庫仍然在強調得到高擴展性的同時你必須犧牲(或者不再需要)事務處理。

          在2010年這篇 Percolator的論文中,Google展示了其網絡搜索是如何保持著與時俱進。Percolator建立于已存類似Bigtable的技術,但是加入了事務以及行和表上的鎖和表變化的通知。這些通知之后會被用于觸發不同階段的計算。通過這樣的方式,個體的更新就可以“滲透”整個數據庫。

          這種方法會讓人聯想到類似Storm(或者是Yahoo的S4)的流處理框架(SPF),然而Percolator內在是以數據作為基礎。SPF使用的一般是消息傳遞而不是數據共享,這樣的話更容易推測出究竟是發生了什么。然而問題也隨之產生:除非你手動的在某個終端上儲存,否則你將無法訪問計算的結果。

          Pregel:可擴展的圖計算

          最終Google還需要挖掘圖數據,比如在線社交網絡的社交圖譜;所以他們開發了 Pregel,并在2010年公布其論文。

          Pregel內在的計算模型比MapReduce復雜的多:基本上每個節點都擁有一個工作者線程,并且對眾多工作者線程進行迭代并行。在每一個所謂的“superstep”中,每一個工作者線程都可以從節點的“收件夾”中讀取消息和把消息發送給其它節點,設置和讀取節點相關值以及邊界,或者投票停止。線程會一直運行,直到所有的節點都被投票停止。此外,還擁有Aggregator和Combiner做全局統計。

          論文陳述了許多算法的實現,比如Google的PageRank、最短路徑、二分圖匹配等。Mikio L. Braun認為,對比MapReduce或SPF,Pregel需要更多實現的再思考。

          Dremel:在線可視化

          在2010年,Google還公布了 Dremel論文。一個為結構化數據設計,并擁有類SQL語言的交互式數據庫。然而取代SQL數據庫使用字段填補的表格,Dremel中使用的是類JSON格式數據(更準確的說,使用Google Protocol buffer格式,這將加強對允許字段的限制)。內部,數據被使用特殊格式儲存,可以讓數據掃描工作來的更高效。查詢被送往服務器,而優秀的格式可以最大性能的輸出結果。

          Spanner:全球分布

          最后 Spanner—— 全球分布式數據庫;Google在2009年提出了Spanner遠景計劃,并在2012年對外公布Spanner論文。Spanner的公布可以說是Google向大數據技術中添的又一把火,Spanner具有高擴展性、多版本、全球級分布以及同步復制等特性。

          跨數據中心的高擴展性及全球分布會對一致性保障提出苛刻的需求 —— 讀寫的外部一致性和基于時間戳的全局讀一致性。為了保障這一點,Google引入了TrueTime API。TureTime API可以同步全球的時間,擁有一個TT.now()的方法,將獲得一個絕對時間,同時還能得到時間誤差。為了保證萬無一失,TrueTime API具有GPS和原子鐘雙保險。也只有這樣的機制才能讓全球范圍內的并發處理得到保障。

          大數據超越MapReduce

          Google并沒有止步于MapReduce,他們在MapReduce不適用的地方開發新方法;當然,對于大數據領域來說這是個福音。MapReduce不是萬能的;當然,你可以更深入一步,比如說將磁盤數據移入內存,然而同樣還存在一些任務的內部結構并不是MapReduce可以擴展的。

          在Google思路以及論文的啟發下,同樣涌現出一些開源項目,比如:Apache Drill、Apache Giraph、斯坦福GPS等等。

          Google近年來每篇論文都有著深遠的影響,同時大數據領域內有很多人必然在翹首以盼Google的下一篇論文。

          原文鏈接: Big Data beyond MapReduce: Google's Big Data papers (編譯/仲浩 審校/王旭東)

          歡迎 @CSDN云計算 微博參與討論,了解更多云信息。

          posted @ 2015-12-11 11:18 小馬歌 閱讀(337) | 評論 (0)編輯 收藏
           
          摘要:7月22日,阿里云正式對外發布了企業級互聯網架構解決方案,該服務由EDAS應用框架、ONS消息隊列、DRDS分布式數據庫組成,能有效解決企業上云后網站過載、性能瓶頸、重復開發等問題。

          7月22日,阿里云正式對外發布了企業級互聯網架構解決方案,該服務由EDAS應用框架、ONS消息隊列、DRDS分布式數據庫組成,能有效解決企業上云后網站過載、性能瓶頸、重復開發等問題。

          云棲大會武漢站,阿里云中間件團隊首次解密這一企業級互聯網架構解決方案。

          EDAS,企業級分布式應用服務

          EDAS(企業級分布式應用服務,Enterprise Distributed Application Service)是一個以阿里巴巴中間件團隊的多款久經沙場的分布式產品作為核心基礎組件構建的企業級云計算解決方案,其充分利用阿里云的ECS等資源,引入淘寶中間件整套成熟的分布式計算框架(包括分布式服務化、鏈路追蹤和穩定性組件等),以應用為中心,幫助企業級客戶在阿里云上輕松構建像淘寶這樣的大型分布式應用服務。

          具備單應用5K運維能力的一站式PaaS平臺

          應用全生命周期管理

          EDAS能夠非常方便的幫助企業級客戶實現一站式的應用生命周期管理,其以“應用”為中心,從應用的創建開始,到應用的部署與擴容,真正意義上實現對大規模互聯網應用在發布和運行過程中的全面管理。

          單應用5K運維能力

          依托于阿里巴巴多年對超大規模互聯網電商系統的運維,所沉淀下來寶貴經驗和大量運維工具都融入于EDAS產品之中,使得其具備對單個應用多達5000臺服務器規模的快速發布能力,包括個性化的Beta和分批發布機制。

          去“中心化”的高性能服務框架

          EDAS所提供的分布式服務框架,源自于阿里巴巴內部使用規模最大的中間件產品——HSF。自2007年誕生以來,HSF服務框架就成為了阿里巴巴內部服務化改造的基礎組件,其超高的性能、久經考驗的穩定性、以及良好的用戶體驗,支撐了生產環境所有系統的服務化調用,日均調用量為2000~3000億次,分鐘峰值最高達到25億次。

          和傳統基于企業服務總線的架構所截然不同的是,HSF服務框架采用了去“中心化”的系統架構,服務的提供者和調用者都直接相連,這樣的系統架構不僅去除了中心單點的風險,還能大大提高調用效率。

          鷹眼:分布式全鏈路跟蹤系統

          EDAS所提供的鷹眼跟蹤系統,通過收集和分析在網絡調用上的日志埋點,可以得到同一次請求上的各個系統的調用鏈關系,有助于梳理應用的請求入口與服務的調用來源、依賴關系,同時,也對分析系統調用瓶頸、估算鏈路容量、快速定位異常有很大幫助。

          全面的基礎和應用監控

          EDAS不僅提供了CPU、內存和Load等維度的基礎監控指標,還提供了針對HTTP入口、提供HSF服務的調用QPS和消費HSF服務的調用QPS等應用層面的監控指標,幫助客戶更為精準全面的對自己的系統進行監控。

          彈性伸縮

          EDAS提供了手動和自動兩種模式的彈性伸縮。通過全面的基礎和應用監控,客戶能夠輕松的實現應用的擴容和縮容。

          限流降級/容量規劃:打造健全的服務化體系

          千萬不要以為使用一套RPC框架就算是完成服務化的工作了——這僅僅是服務化的冰山一角,尤其是針對企業級的大規模互聯網應用,使用RPC框架進行系統的服務化改造后,所帶來的服務治理的挑戰,才是企業級系統服務化的開始。EDAS提供了一系列的服務治理工具,能夠幫助企業級客戶打造健全的服務化體系。

          限流降級

          服務的限流能夠幫助客戶在面對大促的時候,從容的做到核心業務與非核心業務的區別對待,最大化的在服務的可用性和用戶的體驗性上達到平衡。

          服務的降級則能夠幫助客戶很好的規避由于依賴的服務不可用而引發的問題。當依賴的服務出現不可用情況,可以自定義的配置規則來確定對應的降級方案。

          這些限流降級工具都已經經受了多次雙十一大促的考驗。

          容量規劃

          EDAS提供了特有的容量規劃功能,通過自動壓測,可以測算出當前系統的容量。同時,通過容量模型(當前系統容量、希望支撐的容量和當前應用機器數等)的建立,能夠持續的對系統進行容量規劃,這將方便客戶對未來流量增長情況下,提前科學準確的預估出應用所需要的機器數。

          EDAS核心功能展示

          posted @ 2015-12-10 19:46 小馬歌 閱讀(282) | 評論 (0)編輯 收藏
           
               摘要: 作者:Benjamin H. Sigelman, Luiz Andr´e Barroso, Mike Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver, Saul Jaspan, Chandan ShanbhagView project onGitHub概述當代的互聯網的服務,通常都是用復雜的、大規模分布式集群來實現的。互聯網應用構...  閱讀全文
          posted @ 2015-12-10 19:45 小馬歌 閱讀(241) | 評論 (0)編輯 收藏
           

          本文介紹了Mac下如何找到AppStore下載的安裝包路徑,以及如何提取出來供以后使用的相關步驟,希望對大家有所幫助。


                  通過遠在大洋彼岸的蘋果服務器下載東西,確實有夠慢啊!AppStore更甚:甚至都經常提示連不上服務器,而有些軟件呢,還必須從AppStore下載安裝,所以沒辦法,誰讓上了蘋果的賊船呢!公司的網速更是不敢恭維,以至于基本上不下東西,除非像這次一樣:手賤的把iPhone6升級到8.2.2了,然后Xcode6.1.1真機調試不成了,所以需要下個Xcode6.2。昨天剛更新的Xcode6.2,沒有看國內有同胞下載下來沒,一般我都是會從官網下載一個保存到百度網盤以供自己和別人使用的。但是迅雷、瀏覽器下載的都很慢,于是我就通過AppStore更新,貌似還有點兒小快呢(不知道是不是心理作用)!

                  但是又有一個問題:AppStore安裝完后會刪除安裝包,而且也不知道路徑在哪兒,這我怎么能容忍!!!因為公司還有好多電腦要裝呢!!!于是乎,就參考網絡上的各種資源,找到了下載的路徑~~~



          廢話不多說了,上步驟(前提:正在安裝一個程序,例如我正在安裝Xcode):

          1.如圖所示:從應用中打開活動監視器:

          技術分享


                  打開后如圖所示:

          技術分享


          2.找到進程storedownloadd(以前的是storeagent進程,到10.10之后是storedownloadd這個進程):

          技術分享


          3.點擊左上角第二個:查看所選進程的信息:

          技術分享




          4.選擇第三個標簽:打開的文件和端口

          技術分享


          5.command + F,找到以.pkg結尾的路徑并且拷貝,如下圖所示:


          技術分享

          6.在Finder中前往文件夾:

          技術分享


          7.粘貼復制的路徑,并且回車

          技術分享


          8.如下圖一樣的pkg包就是下載的安裝包

          技術分享



                  注意,這一點非常重要第一:不要把這個包早拷出來:因為還沒有下載完成;第二:不要等安裝完再拷:安裝完系統會把這個包刪除的。一定要抓住機會,在系統安裝程序的時候以迅雷不及掩耳盜鈴兒響叮當之勢,把它拉出來~~~


          例如下載的Xcode:

                  正在下載:

          技術分享

                  快完了,一定要看住:

                  技術分享

                  我這個是下載完了的,因為我打開了Xcode,所以桌面彈出了一個警告框讓我關閉,我直接拖出來了,所以還沒有出現正在安裝。如果沒有打開正在安裝的程序,這里會顯示:正在安裝,就是這個時候抓住這一瞬間,把pkg拖出來,完工~~~


                  現在好了,整個世界平靜了,下載的軟件被我們揪住了,然后雙擊安裝即可。安裝完后還可以拷到其他的電腦上進行安裝,省的再次下載了~~~

          技術分享


                  通過這種方式得到的安裝包和從蘋果官網下載的安裝包不一樣:蘋果官網下載的時后綴為.dmg的鏡像,里面包含.pkg的安裝包,而這個直接就是pkg的包,雙擊安裝即可~~~


                  希望對大家有所幫助!!!




          本文出自 “一毛” 博客,請務必保留此出處http://winann.blog.51cto.com/4424329/1619352

          posted @ 2015-10-21 12:29 小馬歌 閱讀(277) | 評論 (0)編輯 收藏
           
          org.springframework.web.util.NestedServletExceptio n: Request processing failed; nested exception is java.lang.IllegalArgumentException: Model has no value for 


          @RequestMapping("/test7/{id}")
              public ModelAndView test7(ModelAndView view, @PathVariable("id") int id) {
                  RedirectView redirectView = new RedirectView("/index{id}");
                  redirectView.setExpandUriTemplateVariables(false);
                  redirectView.setExposeModelAttributes(false);
                  view.setView(redirectView);
                  view.addObject("test", "test");
                  return view;
              }
          posted @ 2015-10-19 21:54 小馬歌 閱讀(600) | 評論 (0)編輯 收藏
           

          from:http://blog.csdn.net/yh_bxhl/article/details/7684318

          頭銜: 技術總監(Chief Technology Officer)

          技術總監最重要的工作職責是領導公司技術團隊,執行、開發和部署公司的互聯網項目,進而保證公司的商業目標得以實現。要做到這一點,技術總監必須能夠參與制定公司的商業戰略,帶領團隊實施互聯網項目的開發,預知各種潛在風險及業務發展瓶頸,并為此做好相應計劃準備。

          職責描述之一:戰略和計劃

          • 與公司創始人緊密協作,對公司的互聯網項目進行合理評估。評估內容包括:市場機會、風險、競爭優勢、市場風險、影響商業成功的技術瓶頸等。
          • 了解技術發展趨勢,發展自己的社會和職業關系,幫組和促進商業目標的成功。
          • 發現和評估各種技術、平臺、框架。
          • 為技術團隊的開發工作制定宏觀戰略目標,包括:目標制定,優先排序,路線圖制定等。
          • 作為公司高層管理者之一,參與監管公司產品發展走向,確保實現公司戰略目標,降低商業風險,優化并合理利用公司資源。技術總監尤其需要在如下方面承擔責任:軟件開發、辦公室軟硬件管理、網絡、和公司通訊設備。
          • 協調公司各部門,評估和推薦相關技術,滿足公司整體IT需求;
          • 建立完整的信息保護機制,保證公司、合作伙伴、和用戶的信息安全。
          • 建立完整的信息安全機制,保護公司數據的機密、完整、以及數據服務的正常運行。
          • 建立完整的災難恢復預案,保證公司產品或服務在遭遇任何攻擊或不可預知的災難的情況下,能夠快速恢復正常服務。
          • 必要情況下,將公司的技術戰略向投資人、管理者、員工、合作伙伴、顧客、和持股人進行解釋說明。

          職責描述之二:項目開發和部署

          • 參與公司互聯網項目的域名選擇,包括任何相關但不會被使用的域名,以避免未來可能的競爭和惡意釣魚行為。管理公司注冊的域名,定期續費,保證所有域名不會丟失。
          • 協調系統管理員,建立公司的企業電子郵件服務。
          • 協調系統管理員,建立軟件開發的版本控制系統。
          • 選型并協調系統管理員,建立開發團隊的內部溝通系統,例如,wiki、博客、即時通訊工具、項目管理工具、bug提交系統等。
          • 協調公司管理高層和潛在客戶,繪制系統用例,為產品的開發形成相應的需求和規范。
          • 協調用戶體驗設計師和產品客戶,為產品繪制原型圖。
          • 協調網站設計師,根據產品原型和已建立的明確需求,為產品進行視覺設計。
          • 協調網站前端設計師,遵循相關制作標準,將設計轉化成前端代碼 (HTML/CSS/JavaScript)。
          • 選擇和確定產品開發模式。
          • 根據需求書和用戶體驗設計建立測試計劃。
          • 制定代碼規范和文檔規范。
          • 評估和選型開發框架,部署基礎系統。
          • 招聘、組建、和管理產品開發團隊(或選擇管理外包開發團隊)。
          • 監控產品開發流程,開發目標拆解、制定長、中、短期開發目標。
          • 建立質量控制體系,保證代碼的高質高效。
          • 監控產品執行性能,選擇和部署相關工具對開發中系統進行性能測試。
          • 管理和控制產品版本更新。
          • 評估和選擇與產品有關的IDC服務商。
          • 建立產品發布過程,負責測試版本和正式版本的切換發布過程。
          • 建立產品流量監控體系。
          • 支持互聯網營銷和管理搜索引擎優化。
          • 建立用戶反饋和支持體系,保證用戶反饋可以傳達到公司管理層和產品團隊。建立用戶幫助服務體系,保證用戶使用產品過程所遇到的問題能夠得到迅速解決。保證產品可用性持續提高。

          職責描述之三:運營管理

          • 保持知識更新,關注行業趨勢,了解最新技術,不斷探索軟件發展的最佳實踐。
          • 參與定義、形成、宣傳公司價值和文化。
          • 確保技術標準和最佳管理實踐在整個組織的貫徹和執行。
          • 建立技術團隊培訓機制,確保知識在整個開發團隊的持續增加和分享。利用各種機會將公司的技術理念、機會、和挑戰傳播給公司的投資人、管理高層、員工、合作伙伴、終端用戶。
          • 確保公司的技術瓶頸在最短時間內,以最低投入方式得以解決。
          • 參與制定年度預算,并確保技術團隊發展和項目開發在年度預算內完成。
          • 參與技術團隊人才招聘,保證公司的雇傭流程和薪金制定與行業和人才市場的通用標準一致。
          • 建立技術團隊各種角色的工作考察標準,根據這些標準對每個員工進行考察。
          • 建立外包團隊工作審核標準,制定服務等級合同,并通過合同對外包團隊進行有效管理。
          posted @ 2015-10-12 08:51 小馬歌 閱讀(675) | 評論 (1)編輯 收藏
          僅列出標題
          共95頁: First 上一頁 8 9 10 11 12 13 14 15 16 下一頁 Last 
           
          主站蜘蛛池模板: 上犹县| 交口县| 拜城县| 刚察县| 黄骅市| 麻栗坡县| 太湖县| 类乌齐县| 东港市| 岐山县| 海晏县| 东乌珠穆沁旗| 陵水| 昌平区| 东乡| 夏河县| 鲜城| 舟曲县| 句容市| 高碑店市| 灯塔市| 布尔津县| 修文县| 高安市| 图们市| 濮阳市| 信丰县| 清涧县| 高邮市| 崇信县| 广丰县| 台江县| 香港| 许昌县| 富宁县| 台中市| 崇文区| 西乌珠穆沁旗| 兴仁县| 蓬溪县| 米林县|