架构设计基础知识
# 前言:
这是我的架构设计学习专栏的第一篇文章,此专栏用于存放我的架构设计学习笔记,内容一部分源于网上免费资料,一部分源于gpt和我自己的理解。专栏目前免费,欢迎订阅此专栏和关注我,随着专栏内容的增多,我可能会收费,所以建议喜欢本专栏的盆友尽早订阅。
这是我的架构设计专栏地址:https://www.nowcoder.com/creation/manager/columnDetail/0ybvLm
我还有另外一个八股专栏,感兴趣的也可以订阅一下:https://www.nowcoder.com/creation/manager/columnDetail/j8ZZk0
1. 什么是架构
架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架。包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则。并由它来指导团队中的每个人思想层面上的一致。涉及四方面:
● 系统性思考的合理决策:比如技术选型、解决方案等。
● 明确的系统骨架:明确系统有哪些部分组成。
● 系统协作关系:各个组成部分如何协作来实现业务请求。
● 约束规范和指导原则:保证系统有序,高效、稳定运行。
因此架构师具备能力:理解业务,全局把控,选择合适技术,解决关键问题、指导研发落地实施。
2. 如果没有架构设计或设计不合理
如果没有架构设计,说明你的系统不够复杂。随着业务的增长,系统由单体应用渐进演化为分布式和微服务化。
系统整体的复杂性越来越高,技术团队可能从一个团队变成多个专业化团队。假如没有架构设计,系统定会是一个无序失控的状态,带来的问题:
应用服务的边界不清晰 |
到底该怎么拆分没有一个明确的原则,研发人员为了所谓微服务化而拆分,而不是从当前业务考虑。导致系统无序地状态,开发效率低。我们系统出现过类似的情况:一个简单项目拆分成8个子服务,问他为什么这么拆分,说微服务化是为了应对以后扩展方便。结果这个项目从2017年到现在都没有再修改过,接手人宁愿新开发一个项目也不愿重构。 |
应用服务层次不清晰,系统耦合严重 |
导致服务依赖出现网状依赖结构,牵一发动全身,后续修改和扩展困难。 |
系统应用服务跟踪问题 |
由于微服务化后,系统逻辑复杂,服务出现问题后,你很难快速地定位问题和修复。这是我们踩过不少坑,我们使用 dubbo 服务化,系统一旦出现问题,一堆人手忙脚乱。 |
系统服务监控问题 |
由于研发人员基本没有服务监控意识,都是出现问题后再想办法如何添加服务监控接口。 |
技术体系失控问题 |
不同的开发团队使用不同的技术栈或者组件,造成公司内部的技术架构失控。甚至研发人员为追求时髦新潮技术,拿应用项目来试验新技术。 |
3. 架构的分类
1.业务架构
业务架构是一家企业最重要的顶层设计,它主要是涉及到业务的流程,规则,边界等。如果业务架构规划设计的不合理,直接影响的就是业务的实际运转。以我们最常提的电商为例,电商业务主要由商品、仓储、订单、支付、用户、客服、购物车等业务模块组成,通过规划好用户在自己app内的业务流程,从而可以确定好各个业务模块之间如何交互。好的顶层设计有利于整体业务运转的高效,以及好的用户体验和企业人员人均价值的提升。
2.应用架构
应用架构是系统设计中很重要的一环。它主要关注的是子系统/子应用之间的关系,也包括子系统设计(尤其是交互设计),开发,部署等。
比如,国内某电商网站的应用包括网页端应用,移动端应用,后端应用,后端应用又会被拆分为若干个业务应用。通过设计好子系统/子应用本身以及他们之间的关系,企业可以更好的管理好自身的应用程序和系统,提高用户体验,降低开发人员维护/沟通协作成本,提高企业运作效率。
3.技术架构
技术架构所关注的点比较广,主要涉及到企业的技术的基础设施以及技术平台,包括软件、硬件、网络、安全、存储等。
4.数据架构
数据是企业生产活动所产生的资源,一定程度上可以说明企业运转到了怎样的程度。数据架构关注点则是企业数据的存储、处理、分析以及共享等。
4.架构设计的目的(3高+其他)
软件架构设计的目的是为了满足软件系统的需求并实现其目标。具体而言,软件架构设计有以下几个目标:
● 高并发:指系统能够处理大量同时发
剩余60%内容,订阅专栏后可继续查看/也可单篇购买
本专栏价格永远为19.9元! 不想当架构师的后端开发工程师不是好码农! 此专栏一方面用于存放我的架构设计学习笔记, 另外我会在本专栏加入一系列最常问八股问题帖子,内容就是我根据自己的面试经历和网上的面经,去筛选八股里面哪些是最常被问到的问题把它们整理出来,大家可以在面试前一两个小时快速把这一系列最常问八股的帖子拿出来看看,临时抱佛脚的效果应该很好