云架构师进阶攻略
https://mp.weixin.qq.com/s/tHRl5OQHY2mNXqKwACCVWw?utm_source=tuicool&utm_medium=referrallinux
1、架构的三个维度和六个层面程序员
1.一、三大架构web
在互联网时代，要作好一个合格的云架构师，须要熟悉三大架构。面试
第一个是IT架构，其实就是计算，网络，存储。这是云架构师的基本功，也是最传统的云架构师应该首先掌握的部分，良好设计的IT架构，能够下降CAPEX和OPEX，减轻运维的负担。数据中心，虚拟化，云平台，容器平台都属于IT架构的范畴。算法
第二个是应用架构，随着应用从传统应用向互联网应用转型，仅仅搞定资源层面的弹性还不够，经常会出现建立了大批机器，仍然撑不住高并发流量。于是基于微服务的互联网架构，愈来愈成为云架构师所必需的技能。良好设计的应用架构，能够实现快速迭代和高并发。数据库，缓存，消息队列等PaaS，以及基于SpringCloud和Dubbo的微服务框架，都属于应用架构的范畴。sql
第三个是数据架构，数据成为人工智能时代的核心资产，在作互联网化转型的同时，每每进行的也是数字化转型，并有战略的进行数据收集，这就须要云架构师同时又大数据思惟。有意识的建设统一的数据平台，并给予数据进行数字化运营。搜索引擎，Hadoop，Spark，人工智能都属于数据架构的范畴。docker
1.二、六个层面数据库
上面的三个维度是从人的角度出发的，若是从系统的角度出发，架构分六个层次。编程
第一个层次是基础设施层，在数据中内心面，会有大量的机架，大量的服务器，并经过交换机和路由器将服务器链接起来，有的应用例如Oracle是须要部署在物理机上的。为了管理的方便，在物理机之上会部署虚拟化，例如Vmware，能够将对于物理机复杂的运维简化为虚拟机灵活的运维。虚拟化采起的运维方式可能是由运维部门统一管理，当一个公司里面部门很是多的时候，每每要引入良好的租户管理，基于Quota和QoS的资源控制，基于VPC的网络规划等，实现从运维集中管理到租户自助使用模式的转换，托生于公有云的OpenStack在这方面作的是比较好的。随着应用架构愈来愈重要，对于标准化交付和弹性伸缩的需求愈来愈大，容器最为软件交付的集装箱，能够实现基于镜像的跨环境迁移，Kubernetes是容器管理平台的事实标准。windows
第二个层次是数据层，也即一个应用的中军大营，若是是传统应用，可能会使用Oracle，并使用大量的存储过程，有大量的表联合查询，成本也每每比较高。可是对于高并发的互联网应用，须要进行微服务的拆分，数据库实例会比较多，使用开源的Mysql是常见的选择，大量的存储过程和联合查询每每会使得微服务没法拆分，性能会比较差，于是须要放到应用层去作复杂的业务逻辑，数据库表和索引的设计很是重要。当并发量比较大的时候，须要实现横向扩展，就须要基于分布式数据库，也是须要基于单库良好的表和索引设计。对于结构比较灵活的数据，能够使用MongoDB数据库，横向扩展能力比较好。对于大量的联合查询需求，能够使用ElasticSearch之类的搜索引擎来作，速度快，更加灵活。
第三个层次是中间件层，由于数据库层每每须要保证数据的不丢失以及一些事务，于是并发性能不可能很是大，因此咱们常常说，数据库是中军大营，不能全部的请求都到这里来，于是须要一层缓存层，用来拦截大部分的热点请求。Memcached适合作简单的key-value存储，内存使用率比较高，并且因为是多核处理，对于比较大的数据，性能较好。可是缺点也比较明显，Memcached严格来说没有集群机制，横向扩展彻底靠客户端来实现。另外Memcached没法持久化，一旦挂了数据就都丢失了，若是想实现高可用，也是须要客户端进行双写才能够。Redis的数据结构比较丰富，提供持久化的功能，提供成熟的主备同步，故障切换的功能，从而保证了高可用性。另外微服务拆分之后，有时候处理一个订单要通过很是多的服务，处理过程会比较慢，这个时候须要使用消息队列，让服务之间的调用变成对于消息的订阅，实现异步处理。RabbitMQ和Kafka是经常使用的消息队列，当事件比较重要的时候，会结合数据库实现可靠消息队列。
第四个层次是基础服务层，有的时候成为中台层，将通用的能力抽象为服务对外提供原子化接口。这样上层能够根据业务需求，经过灵活的组合这些原子化接口，灵活的应对业务需求的变化，实现能力的复用，以及数据的统一管理，例如用户数据，支付数据，不会分散到各个应用中。另外基础服务层称为应用和数据库和缓存的一个分界线，不该该全部的应用都直接连数据库，一旦出现分库分表，数据库迁移，缓存选型改变等，影响面会很是大，几乎没法执行。若是将这些底层的变动拦截在基础服务层，上层仅仅使用基础服务层的接口，这样底层的变化会对上层透明，能够逐步演进。
第五个层次是业务服务层，或者组合服务层，大部分的业务逻辑都是在这个层面实现，业务逻辑比较面向用户，于是会常常改变，因此须要组合基础服务的接口进行实现。在这一层，会常常进行服务的拆分，实现开发独立，上线独立，扩容独立，容灾降级独立。微服务的拆分不该该是一个运动，而应该是一个遇到耦合痛点的时候，不断解决，不断演进的一个过程。微服务拆分以后，有时候须要经过分布式事务，保证多个操做的原子性，也是在组合服务层来实现的。
第六个层次是用户接口层，也即对终端客户呈现出来的界面和APP，可是却不只仅是界面这么简单。这一层有时候称为接入层。在这一层，动态资源和静态资源应该分离，静态资源应该在接入层作缓存，使用CDN进行缓存。也应该UI和API分离，界面应该经过组合API进行数据拼装。API会经过统一的API网关进行统一的管理和治理，一方面后端组合服务层的拆分对APP是透明的，一方面当并发量比较大的时候，能够在这一层实现限流和降级。
为了支撑这六个层次，在上图的左侧是一些公共能力。
-
持续集成和持续发布是保证微服务拆分过程当中的快速迭代，以及变动后保证功能不变的，不引入新的Bug。
-
服务发现和服务治理是微服务之间互相的调用，以及调用过程当中出现异常状况下的熔断，限流，降级策略。
-
大数据和人工智能是经过收集各个层面的数据，例如用户访问数据，用户下单数据，客服询问数据等，结合统一的中台，对数据进行分析，实现智能推荐。
-
监控与APM是基础设施的监控和应用的监控，发现资源层面的问题以及应用调用的问题。
做为一个云架构师仍是很复杂的，千里之行，始于足下，让咱们慢慢来。
2、了解云计算的历史演进与基本原理
在一头扎进云计算的汪洋大海以前，咱们应该先有一个全貌的了解，有人说了解一个知识的起点，就是了解他的历史，也就是知道他是如何一步一步到今天的，这样如此庞大的一个体系，实际上是逐步加进来的，这样的知识体系对咱们来讲，就不是一个冷冰冰的知识网，而是一个有血有肉的人，咱们只要沿着演进的线索，一步一步摸清楚他的脾气就能够了。
如何把云计算讲的通俗易懂，我本人思考了半天，最终写下了下面这篇文章。
在这里，我把核心的要点在这里写一下：
第一：云计算的本质是实现从资源到架构的全面弹性。所谓的弹性就是时间灵活性和空间灵活性，也即想何时要就何时要，想要多少就要多少。
资源层面的弹性也即实现计算、网络、存储资源的弹性。这个过程经历了从物理机，到虚拟化，到云计算的一个演进过程。
架构层面的弹性也即实现通用应用和自有应用的弹性扩展。对于通用的应用，多集成为PaaS平台。对于本身的应用，经过基于脚本的Puppet, Chef, Ansible到基于容器镜像的容器平台CaaS。
第二：大数据包含数据的收集，数据的传输，数据的存储，数据的处理和分析，数据的检索和挖掘等几个过程。
当数据量很小时，不多的几台机器就能解决。慢慢的，当数据量愈来愈大，最牛的服务器都解决不了问题时，怎么办呢？这时就要聚合多台机器的力量，你们齐心合力一块儿把这个事搞定，众人拾柴火焰高。
第三：人工智能经历了基于专家系统的计划经济，基于统计的宏观调控，基于神经网络的微观经济学三个阶段。
3、开源软件是进阶的利器
架构师除了要掌握大的架构和理论以外，指导落地也是必备的技能，所谓既要懂设计模式，也要懂代码。那从哪里去学习这些良好的，有借鉴意义的，能够落地的架构实践呢？
这个世界上仍是有不少有情怀的大牛的，尤为是程序员里面，他们喜欢作一件什么事情呢？开源。不少软件都是有闭源就有开源，源就是源代码。当某个软件作的好，全部人都爱用，这个软件的代码呢，我封闭起来只有我公司知道，其余人不知道，若是其余人想用这个软件，就要付我钱，这就叫闭源。可是世界上总有一些大牛看不惯钱都让一家赚了去。大牛们以为，这个技术你会我也会，你能开发出来，我也能，我开发出来就是不收钱，把代码拿出来分享给你们，全世界谁用均可以，全部的人均可以享受到好处，这个叫作开源。
很是建议你们了解，深刻研究，甚至参与贡献开源软件，由于收益匪浅。
第一：经过开源软件，咱们能够了解大牛们的架构原则，设计模式。
其实我们平时的工做中，是很难碰到大牛的，他多是你渴望而不可及的公司的员工，甚至在国外，你要想进这种公司，不刷个几年题目，面试个N轮是进不去的。即使进去了，他多是公司的高层，天天很忙，不怎么见获得他，就算当面讨教，时间也不会很长，很难深刻交流。也有的大牛会选择自主创业，或者是自由职业者，神龙见首不见尾，到了大公司都见不到。
可是感谢互联网和开源社区，将大牛们拉到了咱们身边，你能够订阅邮件组，能够加入讨论群，能够看到大牛们的设计，看到不少人的评论，提问，还有大牛的回答，能够看到大牛的设计也不是一蹴而就完美的，看到逐渐演进的过程，等等。这些都是可以帮助咱们快速提高水平的地方，有的时候，拿到一篇设计，都要查资料看半天，一开始均可能好多的术语都看不懂，不要紧肯下他，当你看blueprints愈来愈顺畅的时候，你就进步了。
第二：经过开源软件，咱们能够学习到代码级的落地实践。
有时候咱们能看到不少大牛写的书和文章，也能看到不少理论的书籍，可是存在一个问题是，理论都懂，可是仍是作很差架构。这是由于没有看到代码，全部的理论都是空中楼阁，当你到了具体的代码设计层面，那些学会的设计模式，没法转化为你本身的实践。
好在开源软件的代码都是公开的，凝结了大牛的心血，也可以看到大牛在具体落地时候的取舍，一切那么真实，看得见，摸得着。经过代码进行学习，配合理论知识，更容易得到第一手的经验，而且在本身作设计和写代码的时候，立刻可以映射到能够参考的场景，让咱们在作本身的系统的时候，少走弯路。
第三：经过开源软件，咱们能够加入社区，和其余技术人员在同一背景下共同进步
大牛咱们每每不容易接触到，正面讨论技术问题的时间更是难能难得，可是没有关系，开源软件构建了一个社区，你们能够在一块儿讨论，你是怎么理解的，别人是怎么理解的，越讨论越交流，越明晰，有时候和比你经验稍微丰富一点的技术人员交流，可能比直接和大牛对话更加有直接做用。大牛的话可能让你消化半天，依然不知所云，大牛可能以为不少普通人以为的难点是显而易见的，不屑去解释。可是社区里面的技术人员，可能和你同样慢慢进步过来的，知道哪些点是当年本身困惑的，若是踩过这一个个的坑，他们一点拨，你就会豁然开朗。
并且每一个人遇到的具体状况不一样，从事的行业不一样，客户的需求不一样，于是软件设计的时候考虑的因素不一样，大牛是牛，可是不必定可以遇到和你同样的场景，可是社区里面，有你的同行业的，背景相近的技术人员，大家能够讨论出符合大家特定场景的解决方案。
第四：经过开源软件，咱们做为我的，比较容易找到工做
咱们面试的时候，经常遇到的问题是，怎么可以把在原来工做中本身的贡献，理解，设计，技术能力。其实我发现不少程序员不能很好的作的这一点，因此形成不少人面试很吃亏。缘由之一是背景信息不对称，例如原来面临的业务上很难的问题，面试官因为不理解背景，并且短期解释不清楚，而轻视候选人的水平，我也遇到过不少面试官才听了几分钟，就会说，这不挺简单的，你这样这样不就好了，而后完全否认大家一个团队忙了三年的事情。缘由之二是不少有能力的程序员不会表达，致使真正写代码的说不明白，可能原来在公司里面一个绩效很是好，一个绩效很是差，可是到了面试官那里就拉平了。缘由之三是新的公司不能肯定你在上家公司作的工做，到这一家都能用的，例如你作的工做有30%是和具体业务场景相关的，70%是通用技术，可能下家公司只会为你的通用技术部分买单。
开源软件的好处就是，参与的人所掌握的技能都是通的，并且你们在同一个上下文里面对话，面试官和候选人之间的信息差比较少。掌握某个开源软件有多难，不用候选人本身说，你们内心都有数。
对于不少技术能力强，可是表达能力较弱的极少数人员来说，talk is cheap, show me the code，代码呈上去，就可以表现出实力来了，并且面试官也不须要根据短短的半个小时了解一我的，能够作不少背景调查。
另外因为掌握的技术的通用的，你到下一家公司，立刻就可以上手，几乎不须要预热时间，对于双方都有好处。
第五：经过开源软件，咱们做为招聘方，比较容易招到相应人员。
若是在创业公司待过的朋友会了解到创业公司招人很难，人员流失很快，并且创业公司每每对于开发进度要求很快，由于你们都在抢时间。于是开源软件对于招聘方来说，也是好消息。首先创业公司没办法像大公司同样，弄这么多的技术大牛，本身彻底落地一套本身的体系，使用开源软件快速搭建一套平台先上线是最好的选择。其次使用开源软件，会使得招聘相对容易，市场上火的开源软件会有大批的从业者，参与各类论坛和社区，比较容易挖到人。最后，开源软件的使用使得新人来了以后没有预热时间，来了就上手，保证开发速度。
那如何快速上手一款开源软件呢？我写了一篇文章
在这篇文章中，我总结了九个步骤。
-
1、手动安装起来，必定要手动
-
2、使用一下，推荐XXX in Action系列
-
3、读文档，读全部的官方文档，记不住，看不懂也要读下来
-
4、了解核心的原理和算法，推荐XXX the definitive guide系列
-
5、看一本源码分析的书，会让你的源码阅读之旅事半功倍
-
6、开始阅读核心逻辑源代码
-
7、编译并Debug源代码
-
8、开发一个插件，或者对组件作少许的修改
-
9、大量的运维实践经验和面向真实场景的定制开发
因此作一个云架构师，必定不能脱离代码，反而要不断的拥抱开源软件。
4、了解Linux基础知识
做为一个云架构师，首要的一点，就是要熟悉Linux的基础知识，基本原理了。
说到操做系统，通常有三个维度，一个是桌面操做系统，一个是移动操做系统，一个是服务器操做系统。
Stack Overflow Developer Survey 2018有这样一个统计，对于开发人员来讲，桌面操做系统的排名是Windows，MacOS，Linux，因此大部分人平时的办公系统都是windows。
固然由于办公的缘由，平时使用windows的比较多，因此在学校里，不少同窗接触到的操做系统基本上都是Windows，可是一旦从事计算机行业，就必定要跨过Linux这道坎。
根据今年W3Techs的统计，对于服务器端，Unix-Like OS占到的比例为近70%。所谓Unix-Like OS 包括下图的Linux，BSD等一系列。
从这个统计能够看出，随着云计算的发展，软件SaaS化，服务化，甚至微服务化，大部分的计算都是在服务端作的，于是要成为云架构师，就必须懂Linux。
随着移动互联网的发展，客户端基本上以Android和iOS为主，下图是Gartner的统计。Android是基于Linux内核的。于是客户端也进入了Linux阵营，不少智能终端，智能设备等开发职位，都须要懂Linux的人员。
学习Linux主要包含两部分，一个是怎么用，一个是怎么编程，背后原理是什么。
对于怎么用，上手的话，推荐《鸟哥的Linux私房菜》，按着这个手册，就可以学会基本的Linux的使用，若是再深刻一点，推荐《Linux系统管理技术手册》，砖头厚的一本书，是Linux运维手边必备。
对于怎么编程，上手的话，推荐《UNIX环境高级编程》，有代码，有介绍，有原理，若是对内核的原理感兴趣，推荐《深刻理解LINUX内核》。
Linux的架构以下图
咱们知道，一台物理机上有不少的硬件，最重要的是CPU，内存，硬盘，网络，可是一个物理机上要跑不少的程序，这些资源应该给谁用呢？固然是你们轮着用，谁也别独占，谁也别饿死。为了完成这件事情，操做系统的内核就起到了大管家的做用，将硬件资源分配给不一样的用户程序使用，而且在适当的时间将资源拿回来，再分配给其余的用户进程，这个过程称为调度。
操做系统的功能之一是系统调用
当用户程序想请求资源的时候，须要调用操做系统的系统调用接口，这是内核和用户态程序的分界线，就像你要打车，要经过打车软件的界面，下发打车指令同样，这样打车软件才会给你调度一辆车。
操做系统的功能之二是进程管理
当一个用户进程运行的时候，内核为他分配的资源，总要有一个数据结构保存，哪些资源分配给了这个进程。分配给这个进程的资源每每包括打开的文件，内存空间等。
操做系统的功能之三是内存管理
每一个进程有独立的内存空间，内存空间是进程用来存放数据的，就像一间一间的仓库。为了进程使用方便，每一个进程内存空间，在进程的角度来看都是独立的，也即都是从0号仓库，1号仓库，一直到N号仓库，都是独享的。可是从操做系统内核的角度来看，固然不可能独享，而是你们共享，M号仓库只有一个，你用他就不能用，这就须要一个仓库调度系统，将用户进程的仓库号和实际使用的仓库号对应起来，例如进程1的10号仓库，对应到真实的仓库是110号，进程2的20号仓库，对应到真实的仓库是120号。
操做系统功能之四是文件系统
对于Linux来说，不少东西都是文件，例如进程号回对应一个文件，创建一个网络链接也对应一个文件。文件系统多种多样，为了可以统一适配，有一个虚拟文件系统的中间层VFS。
操做系统功能之五是设备管理
设备分两种，一种是块设备，一种是字符设备，例如硬盘就是块设备，能够格式化为文件系统，再如鼠标和键盘的输入输出是字符设备。
操做系统功能之六是网络管理
其实对于Linux来说，网络也是基于设备和文件系统的，可是因为网络有本身的协议栈，要遵循TCP/IP协议栈标准。
对于Linux的基础知识方面，我写了几篇文章以下。
5、了解数据中心和网络基础知识
云平台固然会部署在数据中内心面，因为数据中内心面的硬件设备也是很是专业的，于是不少地方机房部门和云计算部门是两个部门，可是做为一个云架构师，须要和机房部门进行沟通，于是须要必定的数据中心知识，在数据中内心面，最难搞定的是网络，于是这里面网络知识是重中之重。
下面这个图是一个典型的数据中心图。
最外层是Internet Edge，也叫Edge Router，也叫Border Router，它提供数据中心与Internet的链接。
第一层core network，包含不少的core switches
-
Available Zone同Edge router之间通讯
-
Available Zone之间的通讯提供
-
提供高可用性链接HA
-
提供Intrusion Prevention Services
-
提供Distributed Denial of Service Attack Analysis and Mitigation
-
提供Tier 1 Load Balancer
第二层也即每一个AZ的最上层，咱们称为Aggregation layer。
第三层是access layer，就是一个个机架的服务器，用接入交换机链接在一块儿。
这是一个典型的三层网络结构，也即接入层、汇聚层、核心层三层。
对于数据中心，我写了几篇文章
除了数据中心之外，哪怕是作应用架构，对于网络的了解也是必须的。
云架构说究竟是分布式架构，既然是分布式，就是去中心化的，于是就须要系统之间经过网络进行互通，于是网络是做为大规模系统架构绕不过去的一个坎。
对于网络的基本原理，推荐书籍《计算机网络-严伟与潘爱民译》，《计算机网络：自顶向下方法》。
对于TCP/IP协议栈的了解，推荐书籍《TCP/IP详解》，《The TCP/IP Guide》
对于
对于网络程序设计，推荐书籍《UNIX网络编程》
若是你想了解网络协议栈的实现，推荐书籍《深刻理解LINUX网络内幕》
这里还自我推荐一下本人写的极客时间专栏《趣谈网络协议》。
其中有个综合场景，串起来全部的网络协议。
6、基于KVM了解计算虚拟化
当物理机搭建完毕以后，接下来就是基于物理机上面搭建虚拟机了。
没有了解虚拟机的同窗，能够在本身的笔记本电脑上用VirtualBox或者Vmware建立虚拟机，你会发现，很容易就能在物理机的操做系统以内再安装多个操做系统，经过这种方式，你能够很方便的在windows办公系统以内安装一个Linux系统。从而保持LInux系统的持续学习。
前面讲linux操做系统的时候，说到操做系统，就是整个系统的管家。应用程序要申请资源，都须要经过操做系统的系统调用接口，向操做系统内核申请将CPU，内存，网络，硬盘等资源分配给他。
这时候你会发现，虚拟机也是物理机上的一个普通进程，当虚拟机内部的应用程序申请资源的时候，须要向虚拟机的操做系统请求。然而虚拟机的操做系统本身自己也没有权限操做资源，于是又须要像物理机的操做系统申请资源。这中间要多一次翻译的工做，完成这件事情的称为虚拟化软件。例如上面说的VirtualBox和Vmware都是虚拟化软件。
可是多一层翻译，就多一层性能损耗，若是虚拟机里面的每个操做都要翻译，都不能直接操做硬件，性能就会差不少，简直没办法用，因而就出现了上图中的硬件辅助虚拟化，也即经过硬件的特殊配置，例如VT-x和VT-d等，让虚拟机里面的操做系统知道，他不是一个原生的操做系统了，是一个虚拟机的操做系统，不能按照原来的模式操做资源了，而是经过特殊的驱动以硬件辅助的方式抄近道操做物理资源。
刚才说的是桌面虚拟化，也就是在你的笔记本电脑上，在数据中内心面，也能够使用Vmware进行虚拟化，可是价格比较贵，若是规模比较大，会采起开源的虚拟化软件qemu-kvm。
对于qemu-kvm来讲，和上面的原理是同样的，其中qemu的emu是emulator的意思，也即模拟器，就是翻译的意思。KVM是一个能够使用CPU的硬件辅助虚拟化的方式，而网络和存储的，须要经过特殊的virtio的方式，提供高性能的设备虚拟化功能。
要了解虚拟化的基本原理，推荐书籍《系统虚拟化——原理与实现》
要了解KVM，推荐两本书籍《KVM Virtualization Cookbook》和《Mastering KVM Virtualization》。
另外KVM和qemu的官方文档也是必需要看的，还有Redhat的官网不少文章很是值得学习。
对于虚拟化方面，我写了如下的文章。
裸用KVM建立虚拟机，体验virtualbox为你作的10件事情
KVM虚拟机镜像那点儿事，qcow2六大功能，内部快照和外部快照有啥区别？
7、基于Openvswitch了解网络虚拟化
当虚拟机建立出来了，最主要的诉求就是要能上网，他能访问到网上的资源，若是虚拟机里面部署一个网站，也但愿别人可以访问到他。
这一方面依赖于qemu-KVM的网络虚拟化，将网络包从虚拟机里面传播到虚拟机外面，这须要物理机内核转换一把，造成虚拟机内部的网卡和虚拟机外部的虚拟网卡。
另一方面就是虚拟机的网络如何可以链接到物理网络里面。物理网络经常称为underlay network，虚拟网络经常称为overlay network，从物理网络到虚拟网络称为网络虚拟化，能很是好的完成这件事情的是一个叫Openvswitch的虚拟交换机软件。
Openvswitch会有一个内核驱动，监听物理网卡，能够将物理网卡上收到的包拿进来。虚拟机建立出来的外部的虚拟网卡也能够添加到Openvswitch上，而Openvswitch能够设定各类的网络包处理策略，将网络包在虚拟机和物理机之间进行传递，从而实现了网络虚拟化。
对于Openvswitch，我主要是经过官方文档进行研究，写下了这个系列。
Openvswitch的入门篇
Openvswitch的操做篇
玩转Openvwitch第二站：Bridge和Controller
玩转Openvswitch第八站：Interface和Tunnel (下)
玩转Openvswitch第八站：Interface和Tunnel (上)
Openvswitch的代码分析篇
8、基于OpenStack了解云平台
当有了虚拟机，而且虚拟机可以上网了以后，接下来就是搭建云平台的时候了。
云是基于计算，网络，存储虚拟化技术的，云和虚拟化的主要区别在于，管理员的管理模式不一样，用户的使用模式也不一样。
虚拟化平台没有多层次的丰富的租户管理，没有灵活quota配额的限制，没有灵活的QoS的限制，多采用虚拟网络和物理网络打平的桥接模式，虚拟机直接使用机房网络，没有虚拟子网VPC的概念，虚拟网络的管理和隔离不能和租户隔离彻底映射起来。对于存储也是，公司采购了统一的存储，也不能和租户的隔离彻底映射起来。
使用虚拟化平台的特色是，对于这个平台的操做彻底由运维部门统一管理，而不能将权限下放给业务部门本身进行操做。由于一旦容许不一样的部门本身操做，你们都用机房网络，在没有统一管控的状况下，很容易网段冲突了。若是业务部门向申请虚拟机，须要经过工单向运维部门统一的申请。固然这个运维部门很适应这种方式，由于原来物理机就是这样管理的。
可是公有云，例如aws就没办法这样，租户千千万万，只能他们本身操做。在私有云里面，随着服务化甚至微服务化的进行，服务数目愈来愈多，迭代速度愈来愈快，业务部门须要更加频繁的建立和消耗虚拟机，若是仍是由运维部统一审批，统一操做，会使得运维部门压力很是大，并且极大限制了迭代速度，于是要引入 租户管理，运维部灵活配置每一个租户的配额quota和QoS，在这个配额里面，业务部门随时能够按照本身的须要，建立和删除虚拟机，无需知会运维部门。每一个部门均可以建立本身的虚拟网络VPC，不一样租户的VPC以前彻底隔离，因此网段能够冲突，每一个业务部门本身规划本身的网络架构，只有少数的机器须要被外网或者机房访问的时候，须要少数的机房IP，这个也是和租户映射起来的，能够分配给业务部门机房网IP的个数范围内，自由的使用。这样每一个部门自主操做，迭代速度就可以加快了。
云平台中的开源软件的表明是OpenStack，建议你们研究OpenStack的设计机制，是在云里面通用的，了解了OpenStack，对于公有云，容器云，都能发现类似的概念和机制。
沿着OpenStack建立虚拟机的过程，我总结了100个知识点，写下了下面的文章。
用OpenStack界面轻松建立虚拟机的你，看得懂虚拟机启动的这24个参数么？
以为OpenStack的网络复杂？其实你家里就有一样一个网络
当发现你的OpenStack虚拟机网络有问题，不妨先试一下这16个步骤
手动用KVM模拟OpenStack Cinder挂载iSCSI卷
不只Docker会使用Control Group，KVM也会使用Cgroup来控制资源分配
经过咱们研究OpenStack，咱们会发现不少很是好的云平台设计模式。
第一：基于PKI Token的认证模式
若是咱们要实现一个Restful API，但愿有个统一的认证中心的话，Keystone的三角形工做模式是经常使用的。
当咱们要访问一个资源，经过用户名密码或者AK/SK登陆以后，若是认证经过，接下来对于资源的访问，不该该总带着用户名密码，而是登陆的时候造成一个Token，而后访问资源的时候带着Token，服务端经过Token去认证中心进行验证便可。
若是每次验证都去认证中心，效率比较差，后来就有了PKI Token，也即Token解密出来是一个有详细租户信息的字符串，这样本地就能够进行认证和鉴权。
第二：基于Role Based Access Control的鉴权模式
对于权限控制，咱们学会比较通用的Role Based Access Control的权限控制模式， 造成“用户-角色-权限”的受权模型。在这种模型中，用户与角色之间，角色与权限之间，通常者是多对多的关系，能够很是灵活的控制权限。
第三：基于Quota的配额管理
能够经过设置计算，网络，存储的quota，设置某个租户本身能够自主操做的资源量。
第四：基于预选和优选两阶段的Scheduler机制
当须要从一个资源池里面，选择一个节点，使用这个节点上的资源的时候，一个通用的Scheduler机制是：
-
首先进行预选，也即经过Filter，将不知足条件的过滤掉。
-
而后进行优选，也即对于过滤后，知足条件的候选人，经过计算权重，选择其中最优的。
第五：基于独立虚拟子网的网络模式
为了每一个租户能够独立操做，于是虚拟网络应该是独立于物理网络的，这样不一样的租户能够进行独立的网络规划而互不影响，也不影响物理网络，当须要跨租户访问，或者要访问物理网络的时候，须要经过路由器。
第六：基于Copy on Write的镜像机制
有时候咱们在虚拟机里面作了一些操做之后，但愿可以把这个时候的镜像保存下来，好随时恢复到这个时间点，一个最最简单的方法就是彻底复制一份，可是因为镜像太大了，这样效率不好。于是采起Copy on write的机制，当打镜像的时刻，并无新的存储消耗，而是当写入新的东西的时候，将原来的数据找一个地方复制保存下来，这就是Copy on Write。
对于Openstack，有一种镜像qcow2就是采起的这样的机制。
这样镜像就像分层同样，一层一层的罗上去。
第七：基于namespace和cgroup的隔离和Qos机制
在OpenStack里面，网络节点的路由器是由network namespace来隔离的。
KVM的占用的CPU和内存，使用Cgroup来隔离的。
网络的QoS使用TC来隔离的。
第八：基于iptables的安全机制
有时候，咱们但愿网络中的节点之间不能相互访问，做为最简单的防火墙，iptables起到了很重要的做用，之后实现ACL机制的，均可以考虑使用iptables。
9、基于Mesos和Kubernetes了解容器平台
搭建完毕虚拟化层和云平台层，接下来就是容器层了。
Docker有几个核心技术，一个是镜像，一个是运行时，运行时又分看起来隔离的namespace和用起来隔离的cgroup。
Docker的镜像也是一种Copy on Write的镜像格式，下面的层级是只读的，全部的写入都在最上层。
对于运行时，Docker使用的namespace除了network namespace外，还有不少，以下表格所示。
Docker对于cgroup的使用是在运行Docker的时候，在路径/sys/fs/cgroup/cpu/docker/下面控制容器运行使用的资源。
可见容器并无使用更新的技术，而是一种新型的交付方式，也即应用的交付应该是一容器镜像的方式交付，容器一旦启动起来，就不该该进入容器作各类修改，这就是不可改变基础设施。
因为容器的镜像不包含操做系统内核，于是小的多，能够进行跨环境的迁移和弹性伸缩。
我写下了下面的文章，总结了几点容器的正确使用姿式。
有了容器以后，接下来就是容器平台的选型，其实swarm, mesos, kubernetes各有优点，也能够在不一样的阶段，选择使用不一样的容器平台。
Docker, Kubernetes, DCOS 不谈信仰谈技术
容器平台选型的十大模式：Docker、DC/OS、K8S谁与当先？
基于Mesos的DCOS更像是一个数据中心管理平台，而非仅仅容器管理平台，他能够兼容Kubernetes的编排，同时也能跑各类大数据应用。
在容器领域，基于Kubernetes的容器编排已经成为事实标准。
当咱们深刻分析Kubernetes管理容器模式的时候，咱们也能看到熟悉的面孔。
在Kubernetes里面，租户之间靠namespace进行隔离，这个不是Docker的namespace，而是Kubernetes的概念。
API Server的鉴权，也是基于Role Based Access Control模式。
Kubernetes对于namespace，也有Quota配置，使用ResourceQuota。
当Kubernetes想选择一个节点运行pod的时候，选择的过程也是经过预选和优选两个阶段。
-
预选(Filtering)
-
PodFitsResources知足资源
-
PodSelectorMatches符合标签
-
PodFitsHost符合节点名称
-
优选(Weighting)
-
LeastRequestedPriority资源消耗最小
-
BalancedResourceAllocation资源使用最均衡
Kubernetes规定了如下的网络模型定义。
-
全部的容器均可以在不使用NAT的状况下同别的容器通讯
-
全部的节点均可以在不使用NAT的状况下同全部的容器通讯
-
容器的地址和别人看到的地址同样
也即容器平台应该有本身的私有子网，经常使用的有Flannel, Calico, Openvswitch都是能够的。
既能够使用Overlay的方式，如图flannel.
也能够使用BGP的方式，如图Calico
10、基于Hadoop和Spark了解大数据平台
对于数据架构的部分，其实经历了三个过程，分别是Hadoop Map-Reduce 1.0，基于Yarn的Map-Reduce 2.0, 还有Spark。
以下图是Map-Reduce 1.0的过程。
Map-Reduce的过程将一个大任务，split称为多个Map Task，分散到多台机器并行处理，将处理的结果保存到本地，第二个阶段，Reduce Task将中间结果拷贝过来，将结果集中处理，取得最终结果。
在Map-Reduce 1.0的时候，跑任务的方式只有这一种，为了应对复杂的场景，将任务的调度和资源的调度分红两层。其中资源的调用由Yarn进行，Yarn无论是Map仍是Reduce，只要向他请求，他就找到空闲的资源分配给他。
每一个任务启动的时候，专门启动一个Application Master，管理任务的调度，他是知道Map和Reduce的。这就是Map-Reduce 2.0以下图。
这里Yarn至关于外包公司的老板，全部的员工都是worker，都是他的资源，外包公司的老板是不清楚接的每个项目的。
Application Master至关于接的每一个项目的项目经理，他是知道项目的具体状况的，他在执行项目的时候，若是须要员工干活，须要向外包公司老板申请。
Yarn是个通用的调度平台，可以跑Map-Reduce 2，就能跑Spark。
Spark也是建立Spark本身的Application Master，用于调度任务。
Spark之因此比较快，是由于前期规划作的好，不是像Map-Reduce同样，每一次分配任务和聚合任务都要写一次硬盘，而是将任务分红多个阶段，将全部在一个Map都作了的合成一个阶段，这样中间不用落盘，可是到了须要合并的地方，仍是须要落盘的。
对于Hadoop和Spark的基本原理，我写了下面的文章。
真正写Map-Reduce程序的时候，有不少的方法论，这里我总结了几个，供您参考。
11、基于Lucene和ElasticSearch了解搜索引擎
当大数据将收集好的数据处理完毕以后，通常会保存在两个地方，一个是正向索引，能够用Hbase，Cassandra等文档存储，一个是反向索引，方便搜索，就会保存在基于Lucene的ElasticSearch里面。
对于Lucene，在职业生涯的早期，写过一个《Lucene 原理与代码分析完整版》有500多页。
对于搜索引擎的通用原理，写了下面的文章。
12、基于SpringCloud了解微服务
最后到了应用架构，也即微服务。
接下来细说微服务架构设计中不得不知的十大要点。
设计要点一：负载均衡 + API 网关
在实施微服务的过程当中，难免要面临服务的聚合与拆分。
当后端服务的拆分相对比较频繁的时候，做为手机 App 来说，每每须要一个统一的入口，将不一样的请求路由到不一样的服务，不管后面如何拆分与聚合，对于手机端来说都是透明的。
有了 API 网关之后，简单的数据聚合能够在网关层完成，这样就不用在手机 App 端完成，从而手机 App 耗电量较小，用户体验较好。
有了统一的 API 网关，还能够进行统一的认证和鉴权，尽管服务之间的相互调用比较复杂，接口也会比较多。
API 网关每每只暴露必须的对外接口，而且对接口进行统一的认证和鉴权，使得内部的服务相互访问的时候，不用再进行认证和鉴权，效率会比较高。
有了统一的 API 网关，能够在这一层设定必定的策略，进行 A/B 测试，蓝绿发布，预发环境导流等等。
API 网关每每是无状态的，能够横向扩展，从而不会成为性能瓶颈。
设计要点二：无状态化与独立有状态集群
影响应用迁移和横向扩展的重要因素就是应用的状态。无状态服务，是要把这个状态往外移，将 Session 数据，文件数据，结构化数据保存在后端统一的存储中，从而应用仅仅包含商务逻辑。
状态是不可避免的，例如 ZooKeeper，DB，Cache 等，把这些全部有状态的东西收敛在一个很是集中的集群里面。
整个业务就分两部分，一个是无状态的部分，一个是有状态的部分。
无状态的部分能实现两点：
-
跨机房随意地部署，也即迁移性。
-
弹性伸缩，很容易地进行扩容。
有状态的部分，如 ZooKeeper，DB，Cache 有本身的高可用机制，要利用到它们本身高可用的机制来实现这个状态的集群。
虽然说无状态化，可是当前处理的数据，仍是会在内存里面的，当前的进程挂掉数据，确定也是有一部分丢失的。
为了实现这一点，服务要有重试的机制，接口要有幂等的机制，经过服务发现机制，从新调用一次后端服务的另外一个实例就能够了。
设计要点三：数据库的横向扩展
数据库是保存状态，是最重要的也是最容易出现瓶颈的。有了分布式数据库能够使数据库的性能随着节点增长线性地增长。
分布式数据库最最下面是 RDS，是主备的，经过 MySQL 的内核开发能力，咱们可以实现主备切换数据零丢失。
因此数据落在这个 RDS 里面，是很是放心的，哪怕是挂了一个节点，切换完了之后，你的数据也是不会丢的。
再往上就是横向怎么承载大的吞吐量的问题，上面有一个负载均衡 NLB，用 LVS，HAProxy，Keepalived，下面接了一层 Query Server。
Query Server 是能够根据监控数据进行横向扩展的，若是出现了故障，能够随时进行替换的修复，对于业务层是没有任何感知的。
另一个就是双机房的部署，DDB 开发了一个数据运河 NDC 的组件，能够使得不一样的 DDB 之间在不一样的机房里面进行同步。
这时候不但在一个数据中内心面是分布式的，在多个数据中内心面也会有一个相似双活的一个备份，高可用性有很是好的保证。
设计要点四：缓存
在高并发场景下缓存是很是重要的。要有层次的缓存，使得数据尽可能靠近用户。数据越靠近用户能承载的并发量也越大，响应时间越短。
在手机客户端 App 上就应该有一层缓存，不是全部的数据都每时每刻从后端拿，而是只拿重要的，关键的，时常变化的数据。
尤为对于静态数据，能够过一段时间去取一次，并且也不必到数据中心去取，能够经过 CDN，将数据缓存在距离客户端最近的节点上，进行就近下载。
有时候 CDN 里面没有，仍是要回到数据中心去下载，称为回源，在数据中心的最外层，咱们称为接入层，能够设置一层缓存，将大部分的请求拦截，从而不会对后台的数据库形成压力。
若是是动态数据，仍是须要访问应用，经过应用中的商务逻辑生成，或者去数据库读取，为了减轻数据库的压力，应用能够使用本地的缓存，也能够使用分布式缓存。
如 Memcached 或者 Redis，使得大部分请求读取缓存便可，没必要访问数据库。
固然动态数据还能够作必定的静态化，也即降级成静态数据，从而减小后端的压力。
设计要点五：服务拆分与服务发现
当系统扛不住，应用变化快的时候，每每要考虑将比较大的服务拆分为一系列小的服务。
这样第一个好处就是开发比较独立，当很是多的人在维护同一个代码仓库的时候，每每对代码的修改就会相互影响。
经常会出现我没改什么测试就不经过了，并且代码提交的时候，常常会出现冲突，须要进行代码合并，大大下降了开发的效率。
另外一个好处就是上线独立，物流模块对接了一家新的快递公司，须要连同下单一块儿上线，这是很是不合理的行为。
我没改还要我重启，我没改还让我发布，我没改还要我开会，都是应该拆分的时机。
再就是高并发时段的扩容，每每只有最关键的下单和支付流程是核心，只要将关键的交易链路进行扩容便可，若是这时候附带不少其余的服务，扩容既是不经济的，也是颇有风险的。
另外的容灾和降级，在大促的时候，可能须要牺牲一部分的边角功能，可是若是全部的代码耦合在一块儿，很难将边角的部分功能进行降级。
固然拆分完毕之后，应用之间的关系就更加复杂了，于是须要服务发现的机制，来管理应用相互的关系，实现自动的修复，自动的关联，自动的负载均衡，自动的容错切换。
设计要点六：服务编排与弹性伸缩
当服务拆分了，进程就会很是的多，于是须要服务编排来管理服务之间的依赖关系，以及将服务的部署代码化，也就是咱们常说的基础设施即代码。
这样对于服务的发布，更新，回滚，扩容，缩容，均可以经过修改编排文件来实现，从而增长了可追溯性，易管理性，和自动化的能力。
既然编排文件也能够用代码仓库进行管理，就能够实现一百个服务中，更新其中五个服务，只要修改编排文件中的五个服务的配置就能够。
当编排文件提交的时候，代码仓库自动触发自动部署升级脚本，从而更新线上的环境。
当发现新的环境有问题时，固然但愿将这五个服务原子性地回滚，若是没有编排文件，须要人工记录此次升级了哪五个服务。
有了编排文件，只要在代码仓库里面 Revert，就回滚到上一个版本了。全部的操做在代码仓库里都是能够看到的。
设计要点七：统一配置中心
服务拆分之后，服务的数量很是多，若是全部的配置都以配置文件的方式放在应用本地的话，很是难以管理。
能够想象当有几百上千个进程中有一个配置出现了问题，是很难将它找出来的，于是须要有统一的配置中心，来管理全部的配置，进行统一的配置下发。
在微服务中，配置每每分为如下几类：
-
一类是几乎不变的配置，这种配置能够直接打在容器镜像里面。
-
第二类是启动时就会肯定的配置，这种配置每每经过环境变量，在容器启动的时候传进去。
-
第三类就是统一的配置，须要经过配置中心进行下发。例如在大促的状况下，有些功能须要降级，哪些功能能够降级，哪些功能不能降级，均可以在配置文件中统一配置。
设计要点八：统一日志中心
一样是进程数目很是多的时候，很难对成千上百个容器，一个一个登陆进去查看日志，因此须要统一的日志中心来收集日志。
为了使收集到的日志容易分析，对于日志的规范，须要有必定的要求，当全部的服务都遵照统一的日志规范的时候，在日志中心就能够对一个交易流程进行统一的追溯。
例如在最后的日志搜索引擎中，搜索交易号，就可以看到在哪一个过程出现了错误或者异常。
设计要点九：熔断，限流，降级
服务要有熔断，限流，降级的能力，当一个服务调用另外一个服务，出现超时的时候，应及时返回，而非阻塞在那个地方，从而影响其余用户的交易，能够返回默认的托底数据。
当一个服务发现被调用的服务，由于过于繁忙，线程池满，链接池满，或者老是出错，则应该及时熔断，防止由于下一个服务的错误或繁忙，致使本服务的不正常，从而逐渐往前传导，致使整个应用的雪崩。
当发现整个系统的确负载太高的时候，能够选择降级某些功能或某些调用，保证最重要的交易流程的经过，以及最重要的资源所有用于保证最核心的流程。
还有一种手段就是限流，当既设置了熔断策略，又设置了降级策略，经过全链路的压力测试，应该可以知道整个系统的支撑能力。
于是就须要制定限流策略，保证系统在测试过的支撑能力范围内进行服务，超出支撑能力范围的，可拒绝服务。
当你下单的时候，系统弹出对话框说 “系统忙，请重试”，并不表明系统挂了，而是说明系统是正常工做的，只不过限流策略起到了做用。
设计要点十：全方位的监控
当系统很是复杂的时候，要有统一的监控，主要有两个方面，一个是是否健康，一个是性能瓶颈在哪里。
当系统出现异常的时候，监控系统能够配合告警系统，及时地发现，通知，干预，从而保障系统的顺利运行。
当压力测试的时候，每每会遭遇瓶颈，也须要有全方位的监控来找出瓶颈点，同时可以保留现场，从而能够追溯和分析，进行全方位的优化。
我会将微服务相关的文章更加细化的写出来。
有关微服务和容器之间的结合，写了下面的文章。
最后。
小弟参加GIAC年度新人评选，马了这么多字，能帮忙投个票吗？请点击原文链接。
刘超 网易云技术架构部总监
长期致力于云计算开源技术的分享，布道和落地，将网易内部最佳实践服务客户与行业。
技术分享：出版《Lucene应用开发解密》，极客时间专栏《趣谈网络协议》，我的公众号《刘超的通俗云计算》文章Kubernetes及微服务系列18篇，Mesos系列30篇，KVM系列25篇，Openvswitch系列31篇，OpenStack系列24篇，Hadoop系列10篇。公众号文章《终于有人把云计算，大数据，人工智能讲明白了》累积10万+
大会布道：InfoQ架构师峰会明星讲师，做为邀请讲师在QCon，LC3，SACC，GIAC，CEUC，SoftCon，NJSD等超过10场大型技术峰会分享网易的最佳实践
行业落地：将网易的容器和微服务产品在银行，证券，物流，视频监控，智能制造等多个行业落地。