架构知识总结——基础篇

前言

随着工作经验的积累，学习的知识从开始的某一领域深入研究到技术面横向扩充，涉及并积累了很多方面的技术经验，但始终没有静下心来系统完备的进行总结。平时会对某一领域的积累进行思考整理，都只是在单一的技术面，缺少从全局领域的视角进行深层次的剖析总结。在极客时间上看到一堂从0学习架构的课程，发现里面课程目录介绍正是自己工作多年来一步步实践过的路程，于是想通过这堂简易课程的学习对自己来一次全局领域的深层次总结。

后面的内容技术不会很深入，但都是各个领域技术知识的介绍，和平时的经验总结。

不想当架构师的IT不是一名合格的程序猿。技术初入者总会有种感觉——架构师那是一个很难企及的层次，架构师能设计出很牛掰的架构、能解决任何问题。相信很多人都是从这样的小猿一步步成长起来的，在这里不发表意见。随着从0开始学习架构，来一步步解析架构师到底需要掌握什么。

基础架构知识面介绍

架构设计的目的是让程序在以解决需求问题的前提下，以最恰当的方式运行。条条道路通京城，通过各种方式总能设计出满足需求的架构，但如何设计出最合适的架构，而不是为了设计架构而设计，这个度不是那么好把控。

下面引用课程中的一段问答：

“架构设计要考虑高性能、高可用、高扩展……这么多高 XX，全部设计完成估计要 1 个月，但老大只给了 1 周时间”

——架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。

架构设计需要面临的几个方面：高性能、高可用、可扩展性和开发成本等；

高性能：在架构方面的体现，纵向拆分为集群，单台机性能不行加节点。横向为功能模块拆分，相当于业务功能分布式处理，每个模块只处理自己范围的逻辑，通过相互间的调用完成复杂的任务场景。横向拆分可能会增加任务执行的复杂度，因为节点间的网络调用可定无法和内部方法调用相比，但是拆分后的功能模块，集群扩展性更自由，可以根据模块需求搭建合适的集群规模，而且由于从以前的内部业务强耦合，到拆分后的业务低耦合，模块内部的处理复杂度也会大幅下降。于是，以前的单体应用，在互联网大并发的场景下无法生存，催生了微服务、技术中台等新名词。

高可用：从架构层次分析，集群也是高可用的一种，单台机宕机不影响系统继续提供服务。常见的高可用有：主主、主从、热备、冷备等。更复杂的场景，考虑网络可用性，还分异地跨机房、跨运营商等。

可扩展性：平常在设计程序架构时，都会根据需求进行长远分析，预测业务需求的发展方向。程序设计上就需要考虑如何来应对可能性的需求变化，以便于在后续需求变化时，程序可以不变动或者以最小变动的代价来支撑，这时候就需要对程序的代码层次进行职责分离。每个层次的代码依据通用的接口协议进行交互，以满足上下层业务变动不影响中间层代码实现。

所以，这时候对于代码层次间接口的定义就显得非常重要，需要抽离出变动业务的通用性，以在业务变动后接口照样能满足需求。比如：一个简单的用户订单系统包含订单管理模块和消息通知模块，当用户订单变动时，需要通知对应的用户。开始出于时间和成本考虑，只需要发送邮件通知对应的用户即可。上线后，用户对于邮件通知的及时性不满意，需要改为通过短信方式通知。如果前期的订单模块和通知模块耦合度紧密，直接以代码实现方式调用，这时候需要改为短信通知，需要变动的模块将不只是修改通知模块，还需要修改订单系统变动时的触发点逻辑。在前期，如果预测到这种需求变化的可能性，在订单模块和消息通知模块间定义通用的接口交互协议，当通知模块发生变动时，对于订单模块无感知，继续按照定义好的接口协议调用即可。对于上述场景，更新一步，可以分离问两个独立服务（订单服务、通知服务），中间以消息队列的方式进行调用。订单模块推送消息通知任务到消息队列，通知模块订阅通知消息队列发送消息，消息通知需求变更引起的逻辑实现调整和服务部署更新将不会影响到订单相关功能。

上面的接口协议，可以理解为稳定层（抽象层），变动逻辑属于变动层（实现层）。通过稳定层进行交互，变动层的修改将会被传递给关联交互层。

低成本、安全和规模：对于互联网产品，服务器涉及经常成百上千，这块的成本是不可能忽视的问题。通过更高效的技术方案，往往能节省的服务器资源是非常可观的。往常原始的一些底层基础服务，在某些场景下已经不能满足业务急剧增长的需求，会促使新的技术创新诞生。比如

NoSQL（Memcache、Redis 等）的出现是为了解决关系型数据库无法应对高并发访问带来的访问压力。

全文搜索引擎（Sphinx、Elasticsearch、Solr）的出现是为了解决关系型数据库 like 搜索的低效的问题。

Hadoop 的出现是为了解决传统文件系统无法应对海量数据存储和计算的问题。

架构安全性，敏感数据的安全性在如今的互联网大环境下越来越突显，史上每次大规模敏感数据泄露对当事的公司的影响非常可怕。所以，架构安全方面的问题需要谨慎对待。常见的安全问题：xss攻击、csrf攻击、sql注入和系统漏洞等，都可能成为被攻击的缺陷点。常用的安全预防手段：服务器网络防火墙、网段和端口隔离，提升密码复杂度等，除此之外，还需要及时更新发现的各种系统和中间件漏洞，预防可能的被攻击点。