最近学习了李运华老师在极客时间的《从0开始学架构》文章，为了理解深刻便于复习思考整理了思维导图笔记，大家可以参考学习。
对于前面几篇文章中的 思维导图原图，有需要的同学可以关注后发私信 ，我会把原图发给你们。后续其他章节的思维导图也会陆续更新。欢迎大家关注、收藏！
前言
现在一些互联网公司的技术都很厉害，比如淘宝、京东。但经过前面对架构的本质、架构的设计原则、架构的设计模式、架构演进等多方位的探讨和阐述，可以发现其实都是业务的不断发展推动了技术的发展。整个互联网行业的技术发展，最后都是殊途同归，都是使用差不多的标准技术架构和分层技术点。
互联网架构框架
互联网的标准技术架构如下图所示，这张图基本上涵盖了互联网技术公司的大部分技术点，不同的公司只是在具体的技术实现上稍有差异，但不会跳出这个框架的范畴。
“存储层”技术
从上面可以看到， 当公司规模发展到一定阶段后，基本上都是基于某个开源方案搭建统一的存储平台。
“开发层”技术
“服务层”技术
互联网业务的不断发展带来了复杂度的不断提升，业务系统也越来越多，系统间相互依赖程度加深。
服务层的主要目标其实就是为了降低系统间相互关联的复杂度。
“服务名字系统”和“服务总线系统”简单对比如下表所示，
消息队列系统基本功能的实现比较简单，但要做到高性能、高可用、消息时序性、消息事务性则比较难。
“网络层”技术
通常情况下，我们在设计高可用和高性能系统的时候，主要关注点在系统本身的复杂度。但是当我们站在一个公司的的角度来思考架构的时候，互联网业务的高性能和高可用需要站在网络层的角度整体设计架构。
用户层技术
“业务层”技术
“平台”技术
思考
Q：既然存储技术发展到最后都是存储平台，为何没有出现存储平台的开源方案，但云计算却都提供了存储平台方案？
A：
1.存储平台的开发成本高，由于存储平台是核心的平台，高可用，高性能是必须的，这就导致需要经验丰富的高级工程师来开发。而云平台作为服务提供商，有能力开发出来存储平台。
2.需要使用存储平台的公司不多，而且一般是大型的公司，小公司的业务规模都不大，对于存储平台的需求基本不高，云平台面向的是所有用户，众口难调，所以提供基础服务。
3.上云方案对于很多小型公司来说，是一种最简单的方式了，成本低，性能可用性都能达到很高的水平。而开源的平台存储受限于几个条件 ：
①涉及到的存储太多，开发测试都需要很大的人力
②小公司没条件采用，大公司有自己的，使用的人不多，不能快速迭代发展
③没有大型公司的参与，无法推广使用。
。。。。。
Q：使用统一的开发框架和开发语言可以让团队开发效率更高，但这样做会带来什么问题？
A:
1.程序没有用适合的语言开发，程序效率低下，比如现在需要开发内存的缓存系统，但团队开发语言是java，java是一门高级语言，适合做业务系统，用java做内存操作内存会效率低下，而且浪费严重。
2.开发框架和开发语言，都是有场景限制的，尺有所短，寸有所长。
3.可能发生“手里有锤子后，看到什么都是钉子”的情况，在业务规模小的时候采用单一语言单一框架，当规模大了还是应该有一定的灵活性，有一个主力的语言和框架，合适的工作用合适语言和框架，而微服务架构的比较适合混合语言和架构的模式。
4.违背了合适原则，本来用C++语言最合适，偏偏使用了Java
5.容易出现思维盲区，有可能有更好的替代品
。。。。。
Q： 为什么可以购买负载均衡和 CDN 服务，但却不能购买多机房和多中心服务？
A： CDN和LB是基于通用技术和协议，实现请求的调度与转发等功能。所以负载均衡和cdn基本是和业务无关，具有通用性；而每个业务对数据的一致性和事务要求都不一样，需要单独设计，所以无法将多机房和多中心作为基础服务对外提供。
Q：虚拟业务域划分的粒度需要粗一些还是要细一些？你建议虚拟业务域的数量大概是多少？
A： 粗一些比较好，本来虚服务域就是来解决系统拆分过细的问题。
虚拟业务域的数量以 5±2原则比较合适。
Q：运维平台或者测试平台，有的公司是由中间件团队负责开发，有的是运维和测试团队自己开发，你觉得两种方式各有什么优缺点，分别适用什么场景呢？
A： 关注点不同，所能设计的产品也会有重点跟非重点的区别，
中间件可能更关注的是功能的实现，重点在于技术。平台架构有保障，代码质量高，开发效率高，但是前期业务沟通成本大；
运维团队可能关注的是平台的运行稳定以及硬件方面的性能；
测试团队在于平台本身功能点的覆盖情况；
所以由专门的团队来处理，让后其他的队伍提需求。
。。。。。。