原文链接
架构的三个维度和六个层面
第一个是IT架构，其实就是计算，网络，存储。这是云架构师的基本功，也是最传统的云架构师应该首先掌握的部分，良好设计的IT架构，可以降低CAPEX和OPEX，减轻运维的负担。数据中心，虚拟化，云平台，容器平台都属于IT架构的范畴。
第二个是应用架构，随着应用从传统应用向互联网应用转型，仅仅搞定资源层面的弹性还不够，常常会出现创建了大批机器，仍然撑不住高并发流量。因而基于微服务的互联网架构，越来越成为云架构师所必需的技能。良好设计的应用架构，可以实现快速迭代和高并发。数据库，缓存，消息队列等PaaS，以及基于SpringCloud和Dubbo的微服务框架，都属于应用架构的范畴。
第三个是数据架构，数据成为人工智能时代的核心资产，在做互联网化转型的同时，往往进行的也是数字化转型，并有战略的进行数据收集，这就需要云架构师同时又大数据思维。有意识的建设统一的数据平台，并给予数据进行数字化运营。搜索引擎，Hadoop，Spark，人工智能都属于数据架构的范畴
三个维度是从人的角度出发的，
如果从系统的角度出发，架构分六个层次。
第一个层次是基础设施层，
在数据中心里面，会有大量的机架，大量的服务器，并通过交换机和路由器将服务器连接起来，有的应用例如Oracle是需要部署在物理机上的。
为了管理的方便，在物理机之上会部署虚拟化，例如Vmware，可以将对于物理机复杂的运维简化为虚拟机灵活的运维。
虚拟化采取的运维方式多是由运维部门统一管理，当一个公司里面部门非常多的时候，往往要引入良好的租户管理，基于Quota和QoS的资源控制，基于VPC的网络规划等，实现从运维集中管理到租户自助使用模式的转换，托生于公有云的OpenStack在这方面做的是比较好的。
随着应用架构越来越重要，对于标准化交付和弹性伸缩的需求越来越大，容器最为软件交付的集装箱，可以实现基于镜像的跨环境迁移，Kubernetes是容器管理平台的事实标准。
第二个层次是数据层，也即一个应用的中军大营，
如果是传统应用，可能会使用Oracle，并使用大量的存储过程，有大量的表联合查询，成本也往往比较高。
但是对于高并发的互联网应用，需要进行微服务的拆分，数据库实例会比较多，使用开源的Mysql是常见的选择，大量的存储过程和联合查询往往会使得微服务无法拆分，性能会比较差，因而需要放到应用层去做复杂的业务逻辑，数据库表和索引的设计非常重要。
当并发量比较大的时候，需要实现横向扩展，就需要基于分布式数据库，也是需要基于单库良好的表和索引设计。
对于结构比较灵活的数据，可以使用MongoDB数据库，横向扩展能力比较好。
对于大量的联合查询需求，可以使用ElasticSearch之类的搜索引擎来做，速度快，更加灵活。
第三个层次是中间件层，
因为数据库层往往需要保证数据的不丢失以及一些事务，因而并发性能不可能非常大，
所以我们经常说，数据库是中军大营，不能所有的请求都到这里来，
因而需要一层缓存层，用来拦截大部分的热点请求。
Memcached适合做简单的key-value存储，内存使用率比较高，而且由于是多核处理，对于比较大的数据，性能较好。
但是缺点也比较明显，Memcached严格来讲没有集群机制，横向扩展完全靠客户端来实现。
另外Memcached无法持久化，一旦挂了数据就都丢失了，如果想实现高可用，也是需要客户端进行双写才可以。
Redis的数据结构比较丰富，提供持久化的功能，提供成熟的主备同步，故障切换的功能，从而保证了高可用性。
另外微服务拆分以后，有时候处理一个订单要经过非常多的服务，处理过程会比较慢，这个时候需要使用消息队列，让服务之间的调用变成对于消息的订阅，实现异步处理。
RabbitMQ和Kafka是常用的消息队列，当事件比较重要的时候，会结合数据库实现可靠消息队列。
第四个层次是基础服务层，有的时候成为中台层，
将通用的能力抽象为服务对外提供原子化接口。
这样上层可以根据业务需求，通过灵活的组合这些原子化接口，灵活的应对业务需求的变化，实现能力的复用，以及数据的统一管理，
例如用户数据，支付数据，不会分散到各个应用中。
另外基础服务层称为应用和数据库和缓存的一个分界线，不应该所有的应用都直接连数据库，
一旦出现分库分表，数据库迁移，缓存选型改变等，影响面会非常大，几乎无法执行。
如果将这些底层的变更拦截在基础服务层，上层仅仅使用基础服务层的接口，这样底层的变化会对上层透明，可以逐步演进。
第五个层次是业务服务层，或者组合服务层，
大部分的业务逻辑都是在这个层面实现，业务逻辑比较面向用户，因而会经常改变，所以需要组合基础服务的接口进行实现。
在这一层，会经常进行服务的拆分，实现开发独立，上线独立，扩容独立，容灾降级独立。
微服务的拆分不应该是一个运动，而应该是一个遇到耦合痛点的时候，不断解决，不断演进的一个过程。
微服务拆分之后，有时候需要通过分布式事务，保证多个操作的原子性，也是在组合服务层来实现的。
第六个层次是用户接口层，也即对终端客户呈现出来的界面和APP，但是却不仅仅是界面这么简单。这一层有时候称为接入层。
在这一层，动态资源和静态资源应该分离，静态资源应该在接入层做缓存，使用CDN进行缓存。
也应该UI和API分离，界面应该通过组合API进行数据拼装。
API会通过统一的API网关进行统一的管理和治理，
一方面后端组合服务层的拆分对APP是透明的，
一方面当并发量比较大的时候，可以在这一层实现限流和降级。
为了支撑这六个层次，在上图的左侧是一些公共能力。
- 持续集成和持续发布是保证微服务拆分过程中的快速迭代，以及变更后保证功能不变的，不引入新的Bug。
- 服务发现和服务治理是微服务之间互相的调用，以及调用过程中出现异常情况下的熔断，限流，降级策略。
- 大数据和人工智能是通过收集各个层面的数据，例如用户访问数据，用户下单数据，客服询问数据等，结合统一的中台，对数据进行分析，实现智能推荐。
- 监控与APM是基础设施的监控和应用的监控，发现资源层面的问题以及应用调用的问题。
了解云计算的历史演进与基本原理
了解一个知识的起点，就是了解他的历史，也就是知道他是如何一步一步到今天的，这样如此庞大的一个体系，其实是逐步加进来的，这样的知识体系对我们来说，就不是一个冷冰冰的知识网，而是一个有血有肉的人，我们只要沿着演进的线索，一步一步摸清楚他的脾气就可以了。
第一：云计算的本质是实现从资源到架构的全面弹性。
所谓的弹性就是时间灵活性和空间灵活性，也即想什么时候要就什么时候要，想要多少就要多少。
资源层面的弹性也即实现计算、网络、存储资源的弹性。这个过程经历了从物理机，到虚拟化，到云计算的一个演进过程。
架构层面的弹性也即实现通用应用和自有应用的弹性扩展。
对于通用的应用，多集成为PaaS平台。
对于自己的应用，通过基于脚本的Puppet, Chef, Ansible到基于容器镜像的容器平台CaaS。
第二：大数据包含数据的收集，数据的传输，数据的存储，数据的处理和分析，数据的检索和挖掘等几个过程。
第三：人工智能经历了基于专家系统的计划经济，基于统计的宏观调控，基于神经网络的微观经济学三个阶段。
开源软件是进阶的利器
架构师除了要掌握大的架构和理论之外，指导落地也是必备的技能，
所谓既要懂设计模式，也要懂代码。
那从哪里去学习这些良好的，有借鉴意义的，可以落地的架构实践呢？
非常建议大家了解，深入研究，甚至参与贡献开源软件，因为收益匪浅。
第一：通过开源软件，我们可以了解大牛们的架构原则，设计模式。
其实咱们平时的工作中，是很难碰到大牛的，他可能是你渴望而不可及的公司的员工，甚至在国外，你要想进这种公司，不刷个几年题目，面试个N轮是进不去的。即便进去了，他可能是公司的高层，每天很忙，不怎么见得到他，就算当面讨教，时间也不会很长，很难深入交流。也有的大牛会选择自主创业，或者是自由职业者，神龙见首不见尾，到了大公司都见不到。
但是感谢互联网和开源社区，将大牛们拉到了我们身边，你可以订阅邮件组，可以加入讨论群，可以看到大牛们的设计，看到很多人的评论，提问，还有大牛的回答，可以看到大牛的设计也不是一蹴而就完美的，看到逐渐演进的过程，等等。这些都是能够帮助我们快速提升水平的地方，有的时候，拿到一篇设计，都要查资料看半天，一开始都可能好多的术语都看不懂，没关系肯下他，当你看blueprints越来越顺畅的时候，你就进步了。
第二：通过开源软件，我们可以学习到代码级的落地实践。
有时候我们能看到很多大牛写的书和文章，也能看到很多理论的书籍，但是存在一个问题是，理论都懂，但是还是做不好架构。这是因为没有看到代码，所有的理论都是空中楼阁，当你到了具体的代码设计层面，那些学会的设计模式，无法转化为你自己的实践。
好在开源软件的代码都是公开的，凝结了大牛的心血，也能够看到大牛在具体落地时候的取舍，一切那么真实，看得见，摸得着。通过代码进行学习，配合理论知识，更容易获得第一手的经验，并且在自己做设计和写代码的时候，马上能够映射到可以参考的场景，让我们在做自己的系统的时候，少走弯路。
第三：通过开源软件，我们可以加入社区，和其他技术人员在同一背景下共同进步
大牛我们往往不容易接触到，正面讨论技术问题的时间更是难能可贵，但是没有关系，开源软件构建了一个社区，大家可以在一起讨论，你是怎么理解的，别人是怎么理解的，越讨论越交流，越明晰，有时候和比你经验稍微丰富一点的技术人员交流，可能比直接和大牛对话更加有直接作用。大牛的话可能让你消化半天，依然不知所云，大牛可能觉得很多普通人觉得的难点是显而易见的，不屑去解释。但是社区里面的技术人员，可能和你一样慢慢进步过来的，知道哪些点是当年自己困惑的，如果踩过这一个个的坑，他们一点拨，你就会豁然开朗。
而且每个人遇到的具体情况不同，从事的行业不同，客户的需求不同，因而软件设计的时候考虑的因素不同，大牛是牛，但是不一定能够遇到和你一样的场景，但是社区里面，有你的同行业的，背景相近的技术人员，你们可以讨论出符合你们特定场景的解决方案。
第四：通过开源软件，我们作为个人，比较容易找到工作
我们面试的时候，常常遇到的问题是，怎么能够把在原来工作中自己的贡献，理解，设计，技术能力。其实我发现很多程序员不能很好的做的这一点，所以造成很多人面试很吃亏。
原因之一是背景信息不对称，例如原来面临的业务上很难的问题，面试官由于不理解背景，而且短时间解释不清楚，而轻视候选人的水平，我也遇到过很多面试官才听了几分钟，就会说，这不挺简单的，你这样这样不就行了，然后彻底否定你们一个团队忙了三年的事情。
原因之二是很多有能力的程序员不会表达，导致真正写代码的说不明白，可能原来在公司里面一个绩效非常好，一个绩效非常差，但是到了面试官那里就拉平了。
原因之三是新的公司不能确定你在上家公司做的工作，到这一家都能用的，例如你做的工作有30%是和具体业务场景相关的，70%是通用技术，可能下家公司只会为你的通用技术部分买单。
开源软件的好处就是，参与的人所掌握的技能都是通的，而且大家在同一个上下文里面对话，面试官和候选人之间的信息差比较少。掌握某个开源软件有多难，不用候选人自己说，大家心里都有数。
对于很多技术能力强，但是表达能力较弱的极少数人员来讲，talk is cheap, show me the code，代码呈上去，就能够表现出实力来了，而且面试官也不需要根据短短的半个小时了解一个人，可以做很多背景调查。
另外由于掌握的技术的通用的，你到下一家公司，马上就能够上手，几乎不需要预热时间，对于双方都有好处。
第五：通过开源软件，我们作为招聘方，比较容易招到相应人员。
如果在创业公司待过的朋友会了解到创业公司招人很难，人员流失很快，而且创业公司往往对于开发进度要求很快，因为大家都在抢时间。
因而开源软件对于招聘方来讲，也是好消息。
首先创业公司没办法像大公司一样，弄这么多的技术大牛，自己完全落地一套自己的体系，使用开源软件快速搭建一套平台先上线是最好的选择。
其次使用开源软件，会使得招聘相对容易，市场上火的开源软件会有大批的从业者，参与各种论坛和社区，比较容易挖到人。
最后，开源软件的使用使得新人来了之后没有预热时间，来了就上手，保证开发速度。
我总结了九个步骤。
- 一、手动安装起来，一定要手动
- 二、使用一下，推荐XXX in Action系列
- 三、读文档，读所有的官方文档，记不住，看不懂也要读下来
- 四、了解核心的原理和算法，推荐XXX the definitive guide系列
- 五、看一本源码分析的书，会让你的源码阅读之旅事半功倍
- 六、开始阅读核心逻辑源代码
- 七、编译并Debug源代码
- 八、开发一个插件，或者对组件做少量的修改
- 九、大量的运维实践经验和面向真实场景的定制开发
所以做一个云架构师，一定不能脱离代码，反而要不断的拥抱开源软件。
了解Linux基础知识