#
傳統MySQL+ Memcached架構遇到的問題
實際MySQL是適合進行海量數據存儲的，通過Memcached將熱點數據加載到cache，加速訪問，很多公司都曾經使用過這樣的架構，但隨著業務數據量的不斷增加，和訪問量的持續增長，我們遇到了很多問題：
MySQL需要不斷進行拆庫拆表，Memcached也需不斷跟著擴容，擴容和維護工作占據大量開發時間。
Memcached與MySQL數據庫數據一致性問題。
Memcached數據命中率低或down機，大量訪問直接穿透到DB，MySQL無法支撐。
跨機房cache同步問題。
眾多NoSQL百花齊放，如何選擇
最近幾年，業界不斷涌現出很多各種各樣的NoSQL產品，那么如何才能正確地使用好這些產品，最大化地發揮其長處，是我們需要深入研究和思考的問 題，實際歸根結底最重要的是了解這些產品的定位，并且了解到每款產品的tradeoffs，在實際應用中做到揚長避短，總體上這些NoSQL主要用于解決 以下幾種問題
少量數據存儲，高速讀寫訪問。此類產品通過數據全部in-momery 的方式來保證高速訪問，同時提供數據落地的功能，實際這正是Redis最主要的適用場景。
海量數據存儲，分布式系統支持，數據一致性保證，方便的集群節點添加/刪除。
這方面最具代表性的是dynamo和bigtable 2篇論文所闡述的思路。前者是一個完全無中心的設計，節點之間通過gossip方式傳遞集群信息，數據保證最終一致性，后者是一個中心化的方案設計，通過 類似一個分布式鎖服務來保證強一致性,數據寫入先寫內存和redo log，然后定期compat歸并到磁盤上，將隨機寫優化為順序寫，提高寫入性能。
Schema free，auto-sharding等。比如目前常見的一些文檔數據庫都是支持schema-free的，直接存儲json格式數據，并且支持auto-sharding等功能，比如mongodb。
面對這些不同類型的NoSQL產品,我們需要根據我們的業務場景選擇最合適的產品。
Redis適用場景，如何正確的使用
前面已經分析過，Redis最適合所有數據in-momory的場景，雖然Redis也提供持久化功能，但實際更多的是一個disk-backed 的功能，跟傳統意義上的持久化有比較大的差別，那么可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那么何時使用 Memcached,何時使用Redis呢？
Redis與Memcached的比較
網絡IO模型
Memcached是多線程，非阻塞IO復用的網絡模型，分為監聽主線程和worker子線程，監聽線程監聽網絡連接，接受請求后，將連接 描述字pipe 傳遞給worker線程，進行讀寫IO, 網絡層使用libevent封裝的事件庫，多線程模型可以發揮多核作用，但是引入了cache coherency和鎖的問題，比如，Memcached最常用的stats 命令，實際Memcached所有操作都要對這個全局變量加鎖，進行計數等工作，帶來了性能損耗。
（Memcached網絡IO模型）
Redis使用單線程的IO復用模型，自己封裝了一個簡單的AeEvent事件處理框架，主要實現了epoll、kqueue和 select，對于單純只有IO操作來說，單線程可以將速度優勢發揮到最大，但是Redis也提供了一些簡單的計算功能，比如排序、聚合等，對于這些操 作，單線程模型實際會嚴重影響整體吞吐量，CPU計算過程中，整個IO調度都是被阻塞住的。
內存管理方面
Memcached使用預分配的內存池的方式，使用slab和大小不同的chunk來管理內存，Item根據大小選擇合適的chunk存 儲，內存池的方式可以省去申請/釋放內存的開銷，并且能減小內存碎片產生，但這種方式也會帶來一定程度上的空間浪費，并且在內存仍然有很大空間時，新的數 據也可能會被剔除，原因可以參考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/
Redis使用現場申請內存的方式來存儲數據，并且很少使用free-list等方式來優化內存分配，會在一定程度上存在內存碎 片，Redis跟據存儲命令參數，會把帶過期時間的數據單獨存放在一起，并把它們稱為臨時數據，非臨時數據是永遠不會被剔除的，即便物理內存不夠，導致 swap也不會剔除任何非臨時數據（但會嘗試剔除部分臨時數據），這點上Redis更適合作為存儲而不是cache。
數據一致性問題
Memcached提供了cas命令，可以保證多個并發訪問操作同一份數據的一致性問題。 Redis沒有提供cas 命令，并不能保證這點，不過Redis提供了事務的功能，可以保證一串 命令的原子性，中間不會被任何操作打斷。
存儲方式及其它方面
Memcached基本只支持簡單的key-value存儲，不支持枚舉，不支持持久化和復制等功能
Redis除key/value之外，還支持list,set,sorted set,hash等眾多數據結構，提供了KEYS
進行枚舉操作，但不能在線上使用，如果需要枚舉線上數據，Redis提供了工具可以直接掃描其dump文件，枚舉出所有數據，Redis還同時提供了持久化和復制等功能。
關于不同語言的客戶端支持
在不同語言的客戶端方面，Memcached和Redis都有豐富的第三方客戶端可供選擇，不過因為Memcached發展的時間更久一 些，目前看在客戶端支持方面，Memcached的很多客戶端更加成熟穩定，而Redis由于其協議本身就比Memcached復雜，加上作者不斷增加新 的功能等，對應第三方客戶端跟進速度可能會趕不上，有時可能需要自己在第三方客戶端基礎上做些修改才能更好的使用。
根據以上比較不難看出，當我們不希望數據被踢出，或者需要除key/value之外的更多數據類型時，或者需要落地功能時，使用Redis比使用Memcached更合適。
關于Redis的一些周邊功能
Redis除了作為存儲之外還提供了一些其它方面的功能，比如聚合計算、pubsub、scripting等，對于此類功能需要了解其實現原理，清 楚地了解到它的局限性后，才能正確的使用，比如pubsub功能，這個實際是沒有任何持久化支持的，消費方連接閃斷或重連之間過來的消息是會全部丟失的， 又比如聚合計算和scripting等功能受Redis單線程模型所限，是不可能達到很高的吞吐量的，需要謹慎使用。
總的來說Redis作者是一位非常勤奮的開發者，可以經常看到作者在嘗試著各種不同的新鮮想法和思路，針對這些方面的功能就要求我們需要深入了解后再使用。
總結：
Redis使用最佳方式是全部數據in-memory。
Redis更多場景是作為Memcached的替代者來使用。
當需要除key/value之外的更多數據類型支持時，使用Redis更合適。
當存儲的數據不能被剔除時，使用Redis更合適。
后續關于Redis文章計劃：
Redis數據類型與容量規劃。
如何根據業務場景搭建穩定，可靠，可擴展的Redis集群。
Redis參數，代碼優化及二次開發基礎實踐。
關于作者
田琪，目前負責新浪微博平臺底層架構與研發工作，之前曾擔任搜狐白社會實時游戲平臺核心架構工作，主要關注webgame, 分布式存儲，nosql 和 erlang 等領域，目前主要從事mysql源代碼的一些深入研究工作，浪微博：http://weibo.com/bachmozart。
摘要: 簡單來說，觀察者模式=發布者+訂閱者。下面是一個有關獵頭的典型的例子。在下面這張圖當中有兩個角色：獵頭和尋找工作的人。找工作的人向獵頭訂閱，告知自己希望得到一份工作，當有新的工作機會的時候，獵頭就會把這個信息通知給曾經向他訂閱過的人。Java代碼Subject接口：1public interface Subject {2 publi...
閱讀全文
$('#formID').on('submit',function () {
$.ajax({
url: 'submit.php',
cache: false,
type: 'POST',
data : $('#formID').serialize(),
success: function(json) {
alert('all done');
}
});
});
-----------------曾國藩箴言（一）----------------
●輕財足以聚人，律己足以服人，量寬足以得人，身先足以率人。
【譯文】輕視財物可以召集人，律己可以讓人敬服，氣量寬廣可以得人心，自己親身先做事可以領導人。
●惟正己可以化人，惟盡己可以服人。
【譯文】只有端正自己可以感化別人，只有開放自己的心才可以服人。
●遇詭詐人變幻百端，不可測度，吾一以至誠待之，彼術自窮。
【譯文】遇到詭秘狡詐的人變化百端，不可以猜測度量，我都用至誠心對待他，他的方法就沒用了。
●功不獨居，過不推諉。
【譯文】有功勞不自己一個人占有，有過錯不推脫。
●不可輕率評譏古人。
【譯文】不可以輕易評論譏諷古人。
●今日所說之話，明日勿因小利害而變。
【譯文】今天講的話，明天不要因為小的利害就改變。
●遇棘手之際，須從耐煩二字痛下功夫。
【譯文】遇到棘手的時候，要從耐煩這兩個字上下功夫。
●勿以小惡棄人大美，勿以小怨忘人大恩。
【譯文】不要因為別人小的壞處而放棄他大的優點，不要因為與別人小的仇怨而忘記他的恩情。
-----------------曾國藩箴言（二）--------------------
●責過太直，使人慚恨，在我便是一過。
【譯文】指責過錯過于直接，讓別人生慚愧而痛恨自己，對我來說就是一種過錯。
●受挫受辱之時，務須咬牙勵志，蓄其氣而長其智。
【譯文】受到挫敗和侮辱時，一定要咬緊牙忍受來激勵志向，繼續志氣，增長智慧。
●行事不可任心，說話不可任口。
【譯文】做事不可以隨心所欲，說話不可以隨口胡說。
●百種弊病，皆從懶生。
【譯文】很多的弊病都是從懶惰生出的。
●守篤實，戒機巧，守強毅，戒剛愎。
【譯文】謹守篤定老實，不要投機取巧，盡收剛強堅毅，不要剛愎自用。
●凡人做一事，便須全副精神注在此一事，不可見異思遷。
【譯文】凡是有人要做一件事，就須把全副精神貫注在這件事上，不可以見異思遷。
---------------曾國藩箴言（三）---------------
●寡言養氣，寡視養神，寡欲養精。
【譯文】少說話可以休養元氣，少看可以休養心神，減少欲望可以休養精氣。
●禮義廉恥，可以律己，不可以繩人。
【譯文】禮義廉恥，可以用來要求自己，卻不能用來要求別人。
●利可共而不可獨，謀可寡而不可眾。獨利則敗，眾謀則泄。
【譯文】利益可以共享不可以獨享，謀劃可以讓少數人知道不可以讓多數人知道，獨享利益就會失敗，謀劃讓多數人知道就會泄露。
●久利之事勿為，眾爭之地勿往。物極則反，害將及矣。
【譯文】能一直產生利益的事不要做，眾人爭奪的好地方不要去。物極必反，禍害就要來了。
●知足則樂，務貪必憂。
【譯文】知足就會快樂，執著貪心就會憂慮。
●處事宜決斷。
【譯文】處理事情應該堅決果斷。
●事到手且莫急，便要緩緩想。想得時切莫緩，便要急急行。
【譯文】事情分配到手上先別急，要慢慢想。想到時不要拖延，要趕快做。
●尖酸語稱快一時，當之者終身怨恨。
【譯文】尖酸刻薄的話讓你一時痛快，可對方卻終身怨恨你。
●凡權要人聲勢赫然時，我不可犯其鋒，亦不可與之狎，敬而遠之，全身全名之道也。
【譯文】凡是掌握權力的重要人物聲名、勢力非常大的時候，我們不要去觸犯他的鋒芒，也不可以和他交好。對他敬而遠之，是保全自己名聲、生命的方法。
●行事常思退一步。
【譯文】做事常常要想到退讓一步。
●慎言謹行，是修己第一事。
【譯文】謹慎自己的言行，是修養自己德行的最重要的事。
logstash日志處理采用隊列ZMQ，壓力會很好的被緩沖，針對高并發的大數據量的日志處理是沒有問題的，日志利用ES存放，就是個基于lucene的全文檢索數據庫，也不存在數據量的問題。
logstash 是一個應用程序日志、事件的傳輸、處理、管理和搜索的平臺。
你可以用它來統一對應用程序日志進行收集管理，提供 Web 接口用于查詢和統計。
方法一：循環元素刪除
// 刪除ArrayList中重復元素
public static void removeDuplicate(List list) {
for (int i = 0; i < list.size() - 1; i++) {
for (int j = list.size() - 1; j > i; j--) {
if (list.get(j).equals(list.get(i))) {
list.remove(j);
}
}
}
System.out.println(list);
}
方法二：通過HashSet剔除
// 刪除ArrayList中重復元素
public static void removeDuplicate(List list) {
Set set = new HashSet(list);
list.clear();
list.addAll(set);
System.out.println(list);
}
方法三： 刪除ArrayList中重復元素，保持順序
// 刪除ArrayList中重復元素，保持順序
public static void removeDuplicateWithOrder(List list) {
Set set = new HashSet();
List newList = new ArrayList();
for (Iterator iter = list.iterator(); iter.hasNext();) {
Object element = iter.next();
if (set.add(element))
newList.add(element);
}
list.clear();
list.addAll(newList);
System.out.println(" remove duplicate " + list);
}
摘要: 除了傳統對于遠程調用的需求，近來移動開發對于api的規范化需要，restful作為一個流行的接口調用方式，值得深入了解。聲明 本文屬于轉載：原文此文為實踐總結，是自己在實踐過程中積累的經驗和"哲學"。部分內容參考相關資料，參考內容請看尾頁。建議對RESTful有一定了解者閱讀!"哲學"不要為了RESTful而RESTful在能表達清楚的情況下，簡單就是美接口路徑設計接口設計原則URI指向...
閱讀全文
UML定義的關系主要有：泛化、實現、依賴、關聯、聚合、組合，這六種關系緊密程度依次加強，分別看一下
1、泛化
概念：泛化是一種一般與特殊、一般與具體之間關系的描述，具體描述建立在一般描述的基礎之上，并對其進行了擴展。在程序中是通過繼承類實現的。比如狗是對動物的具體描述，在面向對象設計的時候一般把狗設計為動物的子類。
表示方法：空心三角形箭頭的實線，子類指向父類
2、實現
概念：實現是一種類與接口的關系，表示類是接口所有特征和行為的實現，在程序中一般通過類實現接口來描述
表示方法：空心三角形箭頭的虛線，實現類指向接口
3、依賴
概念：是一種使用的關系，即一個類的實現需要另一個類的協助，所以要盡量不使用雙向的互相依賴，在程序中一般表現為類A中的方法需要類B的實例作為其參數或者變量，而類A本身并不需要引用類B的實例作為其成員變量。
表示方法：虛線箭頭，類A指向類B。
4、關聯
概念：表示類與類之間的聯接,它使一個類知道另一個類的屬性和方法，這種關系比依賴更強、不存在依賴關系的偶然性、關系也不是臨時性的，一般是長期性的，在程序中被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個類型為被關聯類B的全局變量
表示方法：實線箭頭，類A指向類B
5、聚合
概念：聚合關聯關系的一種特例，是強的關聯關系。聚合是整體和個體之間的關系，即has-a的關系，整體與個體可以具有各自的生命周期，部分可以屬于多個整體對象，也可以為多個整體對象共享。程序中聚合和關聯關系是一致的，只能從語義級別來區分；
表示方法：尾部為空心菱形的實線箭頭（也可以沒箭頭），類A指向類B
6、組合
概念：組合也是關聯關系的一種特例。組合是一種整體與部分的關系，即contains-a的關系，比聚合更強。部分與整體的生命周期一致，整體的生命周期結束也就意味著部分的生命周期結束，組合關系不能共享。程序中組合和關聯關系是一致的，只能從語義級別來區分。
表示方法：尾部為實心菱形的實現箭頭（也可以沒箭頭），類A指向類B
近來看到CSDN上有個CTO俱樂部，里面聊得是不亦樂乎。我懷著無比崇敬的態度，拜讀了一下牛人們的發言。
里面有個哥們發起一個話題：
“CTO, 你多久沒有寫程序了？”。
有人回答：“不寫代碼的CTO,屬于......這公司問題大了!”。
看到這里，我就趕緊撤了，怕忍不住反駁幾句，反而遭到牛人們的群毆。試想，一個上點規模的IT公司，還得靠CTO來寫程序的話，那是不是才叫問題大了呢。當然，我沒有做過CTO，所以我有我的不同看法，而且還愿意表達出來，無知者無畏。我情愿相信：我所理解的CTO跟這位CTO所理解的是兩回事。所以我想，如果有人能把CTO的職責給標準化了，也許就不會有這么多的爭論了。
同樣的道理，關于架構師的定義，大家也有著不同的理解。什么是架構師？架構師有哪些職責？我覺得有必要提前明確一下，要不然大家溝通起來也會產生類似問題，子說子理，卯說卯理，但是壓根說得不是一碼子事。
0.1 什么是架構師
曾經有這么個段子：
甲：我已經應聘到一家中型軟件公司了，今天上班的時候，全公司的人都來歡迎我。
乙：羨慕ing，都什么人來了？
甲：CEO、COO、CTO、All of 程序員，還有會計、司機都來了。
乙：哇，他們太重視你了，人才啊，這么多人迎接你！
甲：沒有啊，就一個人！
乙：靠，#%￥$%...
很多的創業公司，一人身兼數職的情形還是很常見的。至少，我是經歷過的，一個人包辦了所有的開發過程，連測試我都做了，絕對的一條龍，但是經常踩鋼絲、騎獨輪車總會有失足的時候，結果有一次，從我手里發出去的光盤母盤，含有病毒僵尸，以至于被迫收回已經推上市場的2萬張光盤，從那之后，我的心臟就開始變得無比堅強，現在就是整個后臺服務都癱瘓了，我也只是微微一笑。其實，一個人身兼架構師和程序員，甚至多種角色，沒什么不妥，后面還會講這個話題，這種現象不是中國特色，跟國外是完全接軌的。我曾經跟米國的一個工程師在msn中聊過類似的話題，發現他們的路子跟咱們沒什么不同，在IT這個行業，我們跟世界的差距只有1天，他們剛弄出來的新東西，我們這里第2天保準見得到。
架構師這個稱呼不是拍腦袋想出來的，是有國際標準（ISO/IEC 42010）可查的。架構師是軟件開發活動中的眾多角色之一，它可能是一個人、一個小組，也可能是一個團隊。微軟對架構師有一個分類參考，我們參考一下，他們把架構師分為4種：企業架構師EA(Enterprise Architect)、基礎結構架構師IA(Infrastructure Architect)、特定技術架構TSA(Technology-Specific Architect)和解決方案架構師SA (Solution Architect)。微軟的這個分類是按照架構師專注的領域不同而劃分的。
EA的職責是決定整個公司的技術路線和技術發展方向。蓋茨給自己的Title就是首席軟件架構師，網易丁磊也喜歡這么稱呼自己，實際上就是EA角色；IA的工作就是提煉和優化技術方面積累和沉淀形成的基礎性的、公共的、可復用的框架和組件，這些都是一個技術型公司傳承下來的最寶貴的財富之一；特定技術架構師TSA，他們主要從事類似安全架構、存儲架構等專項技術的規劃和設計工作；SA的工作則專于解決方案的規劃和設計，“解決方案”這個詞在中國已經到了嚴重泛濫的程度，大忽悠們最喜歡把它掛在嘴邊。所謂解決方案，就是把產品、技術或理論，不斷地進行組合，來創造出滿足用戶需求的選擇。售前工程師一般都是帶著它到客戶那里去發揮的。
大公司會把各種類型的架構師分得很清楚，小公司一般就不那么講究了，架構師多數是是IA+TSA+SA，一人包打天下，所以說大公司出專才，小公司出全才。
實際工作中，我們也經常會見到另一種比較簡單的分類方式，把架構師分為軟件架構師和系統架構師。軟件架構師基本上是TSA+IA，這也是程序員最容易突破，最可能走上的一條道路，比如JAVA架構師、DotNet架構師、LAPM架構師等等，我后面所講的內容都是與軟件架構師的相關的話題。系統架構師實際上是SA+TSA，更著力于綜合運用已有的產品和技術，來實現客戶期望的需求。系統架構師要求通曉軟、硬件兩方面的知識，所以它的知識體系相對龐雜。關于系統架構師的話題，我們可以稍后再作討論。
0.2 架構師的職責
架構師需要參與項目開發的全部過程，包括需求分析、架構設計、系統實現、集成、測試和部署各個階段，負責在整個項目中對技術活動和技術說明進行指導和協調。
架構師主要職責有4條：
1、確認需求
在項目開發過程中，架構師是在需求規格說明書完成后介入的，需求規格說明書必須得到架構師的認可。架構師需要和分析人員反復交流，以保證自己完整并準確地理解用戶需求。
2、系統分解
依據用戶需求，架構師將系統整體分解為更小的子系統和組件，從而形成不同的邏輯層或服務。隨后，架構師會確定各層的接口，層與層相互之間的關系。架構師不僅要對整個系統分層，進行“縱向”分解，還要對同一邏輯層分塊，進行“橫向”分解。
軟件架構師的功力基本體現于此，這是一項相對復雜的工作。
3、技術選型
架構師通過對系統的一系列的分解，最終形成了軟件的整體架構。技術選擇主要取決于軟件架構。
Web Server運行在Windows上還是Linux上？數據庫采用MSSql、Oracle還是Mysql？需要不需要采用MVC或者Spring等輕量級的框架？前端采用富客戶端還是瘦客戶端方式？類似的工作，都需要在這個階段提出，并進行評估。
架構師對產品和技術的選型僅僅限于評估，沒有決定權，最終的決定權歸項目經理。架構師提出的技術方案為項目經理提供了重要的參考信息，項目經理會從項目預算、人力資源、時間進度等實際情況進行權衡，最終進行確認。
4、制定技術規格說明
架構師在項目開發過程中，是技術權威。他需要協調所有的開發人員，與開發人員一直保持溝通，始終保證開發者依照它的架構意圖去實現各項功能。
架構師與開發者溝通的最重要的形式是技術規格說明書，它可以是UML視圖、Word文檔，Visio文件等各種表現形式。通過架構師提供的技術規格說明書，保證開發者可以從不同角度去觀察、理解各自承擔的子系統或者模塊。
架構師不僅要保持與開發者的溝通，也需要與項目經理、需求分析員，甚至與最終用戶保持溝通。所以，對于架構師來講，不僅有技術方面的要求，還有人際交流方面的要求。
0.3 架構師的誤區
1、架構師就是項目經理
架構師不是項目經理。項目經理側重于預算控制、時間進度控制、人員管理、與外部聯系和協調等等工作，具備管理職能。一般小型項目中，常見項目經理兼架構師。
2、架構師負責需求分析
架構師不是需求分析員。需求分析人員的工作是收集需求和分析需求，并與最終用戶、產品經理保持聯系。架構師只對最終的需求審核和確認，提出需求不清和不完整的部分，他會跟需求分析員時刻保持聯系。架構師是技術專家，不是業務專家。
3、架構師從來不寫代碼
這是一個尚存爭論的問題。目前有兩種觀點：
觀點1：架構師不寫代碼，寫代碼純體力活，架構師寫代碼大材小用。架構師把UML的各種視圖交給開發人員，如果有不明確的地方，可以與架構師隨時溝通。
觀點2：架構師本來自于程序員，只是比程序員站的層面更高，比程序員唯一多的是經驗和知識，所以架構師也免不了寫代碼。
我個人覺得這兩種說法是與架構師的出身和所處的環境有關。
架構師首先是一個技術角色，所以一定是來自于技術人員這個群體，比如系統架構師，多是來自于運維人員，可能本身代碼寫得并不多，或者說寫不出來很漂亮的代碼。軟件架構師多是來自于程序員，有著程序員的血統和情懷，所以在項目開發過程中，可能會寫一些核心代碼。我們的理想是架構師不用寫代碼，但事實上有時候過于理想。架構師寫不寫代碼，可能取決于公司的規模、文化、開發人員的素質等現實情況。另外，架構師也不是跟程序員界限分得那么清楚，按照能力也有高中低之分，寫不寫代碼不是區分兩者的根本標準。
0.4 架構師的基本素質
周星馳有個片子《喜劇之王》，劇中的尹天仇整天揣著本《演員的自我修養》，一個好演員不僅需要天賦，也需要一定的理論指導，無師自通的人畢竟是少數。架構師的成長過程也是這樣。從普通程序員到高級程序員，再到架構師，是一個經驗積累和思想升華的過程。經驗積累是一個方面，素質培養是另一個方面，兩者相輔相成，所以我覺得有必要把架構師的所要具備的素質羅列一下，作為程序員努力的方向。
1、溝通能力
為了提高效率，架構師必須贏得團隊成員、項目經理、客戶或用戶認同，這就需要架構師具有較強的溝通能力。溝通能力是人類最普遍性的素質要求，技術人員好像容易忽略，想成為架構師就不能忽略。千萬不要抱著這樣的觀念：懷才跟懷孕似的，時間久了總會被人發現的。還是天橋上賣大力丸的哥們說得對：光說不練假把式，光練不說傻把式。看看你周圍的頭頭腦腦們，哪一個不是此中高手，我們千萬不要鄙視，認為這是阿諛奉承、投機鉆營，凡事都要看到積極的一面，“溝通”的確是一種能力。我認為自己是一個略內向的人，因為我是農村出來的孩子，普通話都說不好，以前或多或少帶有點自卑感，幻想著是金子總會發光，所以在職業生涯中吃了不少虧。現在，我深深懂得了溝通的重要性，我會很主動地跟同事們，跟老大們不定時地溝通，感覺工作起來順暢多了。
這一條我認為最為重要，所以排在首位。我甚至認為下面幾條都可以忽略，唯一這一條得牢記，而且要常常提醒自己。
2、領導能力
架構師能夠推動整個團隊的技術進展，能在壓力下作出關鍵性的決策，并將其貫徹到底。架構師如何來保證這種執行力？這就需要架構師具有領導能力。
架構師的領導能力的取得跟項目經理不太一樣。項目經理主要負責解決行政管理，這種能力與技術關系不大，他有人權和財權，再扯上一張“領導”的虎皮，采用“胡蘿卜加大棒”的方式，基本上可以保證執行力。架構師在項目里面可能更多地使用非正式的領導力，也就是我們常說的影響力，里面包括個人魅力、技術能力、知識傳遞等等。
3、抽象思維和分析能力
架構師必須具備抽象思維和分析的能力，這是你進行系統分析和系統分解的基本素質。只有具備這樣的能力，架構師才能看清系統的整體，掌控全局，這也是架構師大局觀的形成基礎。你如何具備這種能力呢？一是來自于經驗，二是來自于學習。架構師不僅要具備在問題領域上的經驗，也需要具備在軟件工程領域內的經驗。也就是說，架構師必須能夠準確得理解需求，然后用軟件工程的思想，把需求轉化和分解成可用計算機語言實現的程度。經驗的積累是需要一個時間過程的，這個過程誰也幫不了你，是需要你去經歷的。但是，如果你有意識地去培養，不斷吸取前人的經驗的話，還是可以縮短這個周期的。這也是我寫作此系列的始動力之一。
4、技術深度和廣度
架構師最好精通1-2個技術，具備這種技術能力可以更加深入的理解有關架構的工作原理，也可以拉近和開發人員的距離，并形成團隊中的影響力。
架構師的技術知識廣度也很重要，需要了解盡可能多的技術，所謂見多識廣，只有這樣，才可能綜合各種技術，選擇更加適合項目的解決方案。有的人說，架構師技術廣度的要求高于技術深度的要求，這是很有道理的。
總而言之，一句話：架構師是項目團隊中的技術權威。