架构篇：什么才是真正的架构设计？
共 8638字，需浏览 18分钟
·
2020-11-02 07:30
剧照 | 《艾米丽在巴黎》
一. 什么是架构和架构本质
在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义，概念是人认识这个世界的基础，并用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。
系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。
子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。
1.2. 模块与组件
1.3. 框架与架构
系统性思考的合理决策：比如技术选型、解决方案等。 明确的系统骨架：明确系统有哪些部分组成。 系统协作关系：各个组成部分如何协作来实现业务请求。 约束规范和指导原则：保证系统有序，高效、稳定运行。
因此架构师具备能力：理解业务，全局把控，选择合适技术，解决关键问题、指导研发落地实施。
架构的本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。
那什么样的系统要考虑做架构设计 技术不会平白无故的出和自驱动发展起来，而架构的发展和需求是基于业务的驱动。
架构设计完全是为了业务，
需求相对复杂. 非功能性需求在整个系统占据重要位置. 系统生命周期长,有扩展性需求. 系统基于组件或者集成的需要. 业务流程再造的需要.
二. 架构分层和分类
2.1. 业务架构（俯视架构）：
2.2. 应用架构（剖面架构，也叫逻辑架构图）：
逻辑分层 子系统、模块定义。 关键类。
接口协议：应用对外输出的接口。 协作关系：应用之间的调用关系。
一种是水平分（横向），按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。 另一种是垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。
配置设计 框架、类库。
编码规范，编码的惯例。 项目模块划分 顶层文件结构设计，比如mvc设计。 依赖关系
2.6. 部署拓扑架构图（实际物理架构图）：
三. 架构级别
系统级：即整个系统内各部分的关系以及如何治理：分层 应用级：即单个应用的整体架构，及其与系统内单个应用的关系等。 模块级：即应用内部的模块架构，如代码的模块化、数据和状态的管理等。 代码级：即从代码级别保障架构实施。
战略设计：业务架构用于指导架构师如何进行系统架构设计。 战术设计：应用架构要根据业务架构来设计。 战术实施：应用架构确定以后，就是技术选型。
四. 应用架构演进
性能需求：使用缓存改善性能 并发需求：使用集群改善并发 读写分离：数据库地读写分离 使用反向代理和cdn加速 使用分布式文件和分布式数据库
复杂性高：以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。可想而知整个项目非常复杂。每次修改代码都心惊胆战， 甚至添加一个简单的功能， 或者修改一个Bug都会带来隐含的缺陷。
技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务， 并且越积 越多。“ 不坏不修”， 这在软件开发中非常常见， 在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。
部署频率低：随着代码的增多，构建和部署的时间也会增加。而在单体应用中， 每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、 影响范围大、 风险高， 这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。
可靠性差：某个应用Bug，例如死循环、内存溢出等， 可能会导致整个应用的崩溃。
扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，不得不在硬件的选择上做出妥协。
阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有的问题， 团队中的每个成员 都必须使用相同的开发语言和框架，要想引入新框架或新技术平台会非常困难。
降低了耦合度：把模块拆分，使用接口通信,降低模块之间的耦合度。
责任清晰：把项目拆分成若干个子项目，不同的团队负责不同的子项目。
扩展方便：增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。
部署方便：可以灵活的进行分布式部署。
提高代码的复用性：比如Service层，如果不采用分布式rest服务方式架构就会在手机Wap商城，微信商城，PC，Android，iOS每个端都要写一个Service层逻辑，开发量大，难以维护一起升级，这时候就可以采用分布式rest服务方式，公用一个service层。
缺点：系统之间的交互要使用远程通信，接口开发增大工作量，但是利大于弊。
易于开发和维护：一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。
单个微服务启动较快：单个微服务代码量较少， 所以启动会比较快。
局部修改容易部署：单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。例如某些服务可使用关系型数据库MySQL；某些微服务有图形计算的需求，可以使用Neo4j；甚至可根据需要，部分微服务使用Java开发，部分微服务使用Node.js开发。
运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务服务的正常运行与协作，这给运维带来了很大的挑战。
分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。
重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题（例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件），但共享库在多语言环境下就不一定行得通了。
五. 衡量架构的合理性
能解决当下业务需求和问题 高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题 前瞻性设计: 能在未来一段时间都能以第2种方式满足业务，从而不会每次当业务进行演变时，导致架构翻天覆地的变化。
5.2. 非业务需求角度
高可用：要尽可能的提高软件的可用性，我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。
文档化：不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。 可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。 高复用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。
安全：组织的运作过程中产生的数据都是具有商业价值的，保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段
六. 常见架构误区
开高走落不到实处
遗漏关键性约束与非功能需求 为虚无的未来埋单而过度设计 过早做出关键性决策 客户说啥就是啥成为传话筒 埋头干活儿缺乏前瞻性 架构设计还要考虑系统可测性 架构设计不要企图一步到位
误区1——架构专门由架构师来做，业务开发人员无需关注：架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。 误区2——架构师确定了架构蓝图之后任务就结束了：架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道“地”在哪？怎么才能落的稳稳当当。 误区3——不做出完美的架构设计不开工：世上没有最好架构，只有最合适的架构,不要企图一步到位。我们需要的不是一下子造出一辆汽车，而是从单轮车→自行车→摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗？ 误区4—— 为虚无的未来埋单而过度设计：在创业公司初期，业务场景和需求边界很难把握，产品需要快速迭代和变现，需求频繁更新，这个时候需要的是快速实现。不要过多考虑未来的扩展，说不定功能做完，效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰，是应该适当的考虑未来的扩展性设计。 误区5——一味追随大公司的解决方案：由于大公司巨大成功的光环效应，再加上从大公司挖来的技术高手的影响，网站在讨论架构决策时，最有说服力的一句话就成了“淘宝就是这么搞的”或者“腾讯 就是这么搞的”。大公司的经验和成功模式固然重要，值得学习借鉴，但如果因此而变得盲从，就失去了坚持自我的勇气，在架构演化的道路上迟早会迷路。 误区6——为了技术而技术：技术是为业务而存在的，除此毫无意义。在技术选型和架构设计中，脱离网站业务发展的实际，一味追求时髦的新技术，可能会将技术发展引入崎岖小道，架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑，理想与现实需要折中。
七. 架构知识体系
初始阶段：LAMP,部署在一台服务器 应用服务器和数据服务器分离 使用缓存改善性能 使用集群改善并发 数据库地读写分离 使用反向代理和cdn加速 使用分布式文件和分布式数据库 业务拆分 分布式服务
分布式应用和服务 分布式静态资源 分布式数据和存储 分布式计算
cdn 方向代理访问资源 本地缓存 分布式缓存
提供系统的可用性 加快响应速度
性能测试 前端优化 应用优化 数据库优化
负载均衡 数据备份 自动发布 灰度发布 监控报警
负载均衡 缓存负载均衡
分布式消息 服务化
xss攻击 sql注入 csr攻击 web防火墙漏洞 安全漏洞 ssl
八. 架构书籍推荐
大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。
近期热门文章推荐：
