架构硬实力

这个章节，基本大家都没有什么争议性，必须是硬实力，拿得出手，能解决技术当前面临的挑战，能解决别人解决不了的问题。

从目前大家遇到的挑战来看，从架构设计要求，我稍微做个总结。

1分层的应用设计思想：SOA，事件驱动等。

SOA这块的内容，我推荐大家去看支付宝首席架构师程立的文章。这块支付宝和淘宝算是一起实践走过来的。但是，程立算是比较早而且很详尽的把支付宝的SOA之路说得非常详细。

2分布式原理：CAP，最终一致性，幂等操作等

这方面是的知识，网上比较多而且很全，也可买一本分布式系统相关的书籍了解。

大型网络应用结构

消息中间件，分布式缓存，负载均衡，集群技术，数据同步等。

上一篇也谈到了中间件，基本上现在大的互联网公司，中间件基本可以与架构组划上等好了。他们基本提供了分布式场景下的应用扩展的大部分基础设施。淘宝在这块的实力比较强，基本都已经开源出来了。常见的分布式缓存Tair,分布式小文件存储TFS,等等。我之前一篇淘宝最具挑战的的架构演变，也谈到。

3高可用，可容灾分布式系统设计能力。

例如，阿里云SLB产品使用开源软件LVS＋keeplived实现4层的负载均衡。

采用淘宝的Tengine实现7层的负载均衡。所有负载均衡均采用集群部署，集群之间实时会话同步，以消除服务器单点，提升冗余，保证服务稳定。在各个地域采用多物理机房部署，实现同城容灾。

SLB在整体设计上让其可用性高达99.99%。且能够根据应用负载进行弹性扩容，在任意一台SLB故障或流量波动等情况下都能做到不中断对外服务。

大容量数据存储和检索系统设计能力：数据库分区，NoSQL，搜索引擎等。

当然，还有自动化部署、回滚机制等，以及监控系统等等。

架构师前瞻性

所谓前瞻性表面听起来还是比较空洞，什么叫前瞻性？这里我谈谈我看到或者观察到的例子，这样来观察，也许更好感受到什么叫前瞻性。

比如，这是当时支付宝程立在谈到支付宝SOA之路的场景。

“瞻前”、“顾后” ――这是我现在体会到的最大挑战。

先谈谈“瞻前”。当业务个性不明显、业务规模也不大时，架构师还是有很多容易模仿的定式与先例的。但当业务的个性与规模到达一定阶段时，一定会有一些别人从未遇到过的非常困难的问题需要你去解决。作为站在企业技术金字塔塔尖上的一群人，当过去的经验用不上，搜索引擎也不能向你提供任何有用的答案，只有独立去思考，去做出重大决定时，如果没有充分的准备，对企业对个人都是巨大的风险。这需要架构师建立未雨绸缪的意识，不断推演未来可能的变化并思索应对之策，持续而有方向地积累知识、发展能力，建立广泛的技术交流圈子，并且“顾后”。

再谈谈“顾后”。架构师的另一个重要的职责是发掘团队中的好苗子，帮助他们，使他们赶上并超越自己。无论这一点是否写入你的KPI，这样做都是必须的。站在架构师的立场看，架构必须有一个好的技术梯队一层层传递下去，才能够有效、持续地贯彻执行，如果只是架构师们冲在前面，背后空了一大片，架构永远只能停留在蓝图上。站在企业的立场看，企业真正的技术实力，不在于已经有怎样的系统或者平台，而在于是否有一个强大而有生命力的技术团队，通过快速复制架构师的技术与经验，可以帮助发展并壮大这样的团队，而企业整体技术实力的提升也促进了架构师提升。

业务产品架构

技术架构的目的是为了服务好业务，技术离开了业务，啥都不是。所以，对于好的架构师来讲，对业务的掌握以及理解，需要一个团队从早期就意识起来。

我用一个例子来举例：语言翻译能力。

将业务语言翻译为产品语言、开发语言的能力很重要。业务需求来自客户或业务部门，收集到的信息是基于业务语言描述。 业务架构师需要学会基于自己的经验知识进行分析，把业务语言转换成产品语言、开发语言。这样在跟产品、研发团队的沟通中，才能完成信息的有效、高保真传递。我早几年前接触过很多大公司的BD，基本就是干着活。能把一个用户的需求，从需求、产品、市场、功能、流程分析出一份详细的需求报告书出来，在与用户确认后，才能需求分析书转到技术部开始架构设计等后续的工作。

一般来讲，公司的很多需求业务模型，都是他们在整理。比如，公司的核心业务介绍等手册。

当然，这里还有好几个方面。比如，对行业的理解、交流沟通能力等等。