架构设计之常识篇

关注
发布于: 2020 年 06 月 30 日
常识，一般指从事各项工作以及进行学术研究所需具备的相关领域内的基础知识。计算这个新兴科学也沉淀了一些常识。
架构演进历程架构演进历程跟人类历史的演进轨迹不谋而合，不停的拆，拆的太散了就的合，每一个阶段面对的问题都是不同的，拆的目的就是为了解决当下的问题。把老师ppt的图直接copy过来构成一个演化的12个版本，最核心的关注点“拆”，为啥要拆？受限于物理机器的能力，就好比一个皇帝总不可能管理全国每个人的吃喝拉撒睡，如果真那样，皇帝迟早被累死了！所以就引入了三省六部的这套机制，分层管理，底层向上层汇报，这下皇帝立马轻松就可以该干嘛就干嘛了。看看古代人的皇帝管理机制就跟现在系统的类似，一个很好的借鉴。学习需要将理论和实践联系起来，一些理论其实在实现中能找到很好的case，这样可以加深自己的理解。
v1
应用程序、文件、数据库部署在同一台物理机器上，随着用户量的增长，受限于硬件资源系统会出现瓶颈，因此可以采用垂直扩展的方式来解决，当垂直方式的不能解决(ROI)，历史演进从大一统到诸侯制度，分封疆土；
v2
应用程序、文件服务器、数据库服务器单独部署当然可以是物理机器、docker、k8s的pod；
v3
任何系统最终的瓶颈还是在于磁盘，也就是IO上面，为了加快访问数据的速度引入了分布式缓存；缓存主要用于加速数据的访问。
v4
随着访问量的增加，应用程序也开始出现瓶颈，应用程序的水平扩展需要注意设计的时候要打造服务stateless，否则扩展会出问题的。
v5
数据库层hold不住大量的读写，开始考虑读写分离；
v6
由于图片等静态资源占用了大量的网络带宽，因此引入CDN(自建或者购买)将静态资源和动态资源分离，由于国内是3大运营商，跨网络节点的交互是有一定的延时；
v7
面对海量数据的存储就需要分库分表，分布式文件系统，当然现在可以上tidb
v8
引入NoSQL，搜友引擎，将搜索从原有系统拆开
v9
业务垂直拆分，应用领域模型落地设计
v10
微服务化及中台化，中台其实就是将拆散的功能能力合并下沉，微服务化的落地需要的是微服务或者ServiceMesh；
v11前面10个阶段本质就是 拆 拆 拆，而拆的这么散，如何自动部署、监控等，就该云原生架构登场了，它focus on在运维和部署；
v12大数据化与智能化，这是一个蓝海阶段。
﻿
注意：多IDC部署
互联网系统架构的核心要素现在市面上的架构设计文档都有几个相同的🏷标签：高并发、高可用、高性能、可扩展、可伸缩、安全。众多的标签中其实有一个潜在的因果关系，高并发就是潜在的因，而高可用、高性能、可扩展、可伸缩、安全都是因为高并发而设计出来的，高并发不是设计出来的而是客观存在的。
﻿
一个潜在的常识就是能通过加硬件解决的问题别搞复杂化。注意ROI😯
总结1.淘宝的案例、微博的案例学到了什么？
从ppt中能可以拆解出一个演讲的套路，先摆问题，在讲解决方案，有代入感。(第一趴：业务发展形势及遇到的困难；第二趴：针对性的解决方案(技术方案及方案的变迁)；第三趴：讨论)这个套路也可以用在架构评审中，先讲清楚问题的背景，在丢出技术方案。
技术和业务是相互成就的，技术要借力业务来展现自己的价值，技术要做到天人合一，所谓的天人合一指的是结合当下的天时地利人和做出合理的选择换个说法就是要根据场景做好balance；
架构是演进的，没有一撮而就的架构，淘宝、微博就是最好的案例，别为了设计一个全能的架构而错失了业务的发展时机。
2.智慧老师讲进入阿里案例
当自己全面否定自己的时候认为或者过的最困难的时候就是要突破的时候，因为外在的压力迫使自己做出改变。
能很快找到问题的关键所在，比有很多解决方案靠谱，有方案而找不到问题的根因，在好的方案也是白扯，况且知道问题了，其实方案就摆在那里。
做事情要预留buffer，你懂得
3.宅米案例
宅米选择了一个细分的市场，而且刚好在百团大战的时候，巨头们无暇顾及，赢得了很好的发展
宅米商业模式存在两个月的空档期，这个空档期其实对于商业运作来说是无利润产生的
宅米的没落 没有所谓的救世主，要有救世主，救世主自己就去搞了，还需要救你么。这个恰恰说明团队在困难的时候往往期待救世主，可以看看《天道》这部电视剧，能很好的理解一些事情，强烈推荐看看。
从独角兽到散伙时间很短，因此人生除了生死没有什么大事了。