#
传统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个技术，具备这种技术能力可以更加深入的理解有关架构的工作原理，也可以拉近和开发人员的距离，并形成团队中的影响力。
架构师的技术知识广度也很重要，需要了解尽可能多的技术，所谓见多识广，只有这样，才可能综合各种技术，选择更加适合项目的解决方案。有的人说，架构师技术广度的要求高于技术深度的要求，这是很有道理的。
总而言之，一句话：架构师是项目团队中的技术权威。