来自
http://blog.qiniu.com/archives/7551
如果要看，最好请看上面的图文，很有意思的故事之路，看完了也就知道《架构师成长之路》了
把感兴趣的记录下来：
架构狮是个是什么狮子
系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。
跨越技术，工程和管理的职位
需求-》（时间人力钱）
架构师的世界里，人力，钱，时间总是至少有一个不够用，通常是三个都不够用。
在这些条件下解决问题就是我们每天所做的。
若都够用的时候，往往意味着更复杂的需求就要来了，很快就会变成全不够了。这才是挑战
业务，产品，运营，技术团队和管理层，架构师都要打交道。
熟悉公司业务需求和战略，提前做好技术上的准备，才能设计出适合团队能力和资源的架构，只考虑技术是做不好的
想做好一个架构师，对技术不精通是不行的。技术，行业和业务一直在发展变化，不跟上这些变化，就只能用一些成熟的套路去解决问题
套路用得多了，最后没准就变成给自己下套了
很多时候需要盖的摩天大楼，不可能依靠自己去生产所有材料和部件。。。。
这个时候就需要决定哪部分自己开发，那些部分寻找云服务，哪些部分使用开源和库
如何组合这些资源，如何挑选 云服务，开源和库，如何平衡风险和成本，这些都是架构师要做的工作
如果不熟悉代码，不持续而深入了解技术，这些事情都做不好。
服务比较标准，但开发投入又比较大的，这时候可以用云服务，或者开源和库，可以节省大量的时间和开发成本
更大的精力是做好自己的特色
做架构设计刚开始先不要想太多，先满足一段时间内的需求，然后在这段时间内研究下一代技术或者完善架构
项目往往会永远面临各种条件上的限制。架构师必须正视各种资源短缺，需求和项目周期的问题
不是所有项目都需要考虑那么长远的性能问题。取舍是做设计时最重要的能力。知道哪些问题重要，必须解决，哪些可以放弃
提前考虑好未来各个关键点如何演进。（现在预见到的许多“未来问题”以后可能会变化，可能变得用不着解决），但如果试图在一开始就解决所有“未来问题”，对资源和技术都是浪费，也会导致你很难作出设计上的决策
架构设计
产品架构的选型，负载扩展
性能很重要，但架构设计要尽量使用业界流行的通用标准，为了通用和易于维护，有时性能上甚至可以做点妥协
选择具体方案的时候，要多看社区评价和讨论，选择质量较高又维护活跃的方案
稳定性是相当重要的指标，如果被比较大的项目使用过，肯定是加分的，单也要看具体的使用情况。有数据可以参考最好了，如果没有就只能看大项目参与者的使用体验分享了。
同样，性能很重要，但不应该仅应该因为性能好就决定，要充分权衡这几个原则
如果项目目标是做到可以水平扩展。系统设计就要尽量解除耦合，降低共享资源的使用，最好做到完全没有共享资源，这样扩展最好
在项目早期会简单一些，只要做到分片短期内都够用了。单以后还得需要考虑热点数据什么的问题
现在多想想，为了就能少点麻烦
作为一个架构师，你得能沟通，能收集过滤关键信息，找出时间，资源和需求间平衡点，才有可能作出一个有实现性的架构方案
然后你还得能谈判，能把你的设计或者战术能讲明白，让别人愿意执行你的方案
在许多时候，你都得跳出“我是来解决架构问题”的框框，站在其他部分角色的立场上考虑问题
很难说一次架构选型是对是错。架构选型本来就是一个权衡过程。
如果使用了成熟的系统架构，优势是它更成熟，但代价是我们需要多维护一种语言写的系统，要修改很难有足够人手
选择的不成熟的系统可能不够完善，但该系统的开发语言我们更熟悉，可控性很强，修补通常也很容易，也不会过于复杂。
如何做选择取决于你的具体目标与条件，并没有标准答案
云服务不是万能解药，但在各种方案间做权衡正式我们架构师最重要的工作之一。
选择的关键就是想清楚对你而言，当前什么是最重要的，会付出什么的代价，同时有什么潜在风险，多大成本能解决
