跳到主要内容

后端架构演进

什么是架构​

软件架构是指设计软件的人为软件赋予的形状，这个形状是指系统如何被划分为组件（Components），各个组件如何排列（Arrangement）, 组件之间如何沟通（Communication，通讯）。

一些“类”架构的概念​

  • 框架: 框架不是架构，框架更多是一种复杂技术的封装，比如 dubbo , dubbo 是为了解决 RPC 在远程调用中的复杂性，屏蔽了一些底层细节，包括 RPC 在实战应用中可能遇到的一些综合性问题，比如服务超时、服务重试、服务熔断、服务降级等这一系列的解决手段，是整体的一个解决方案；

  • SpringCloud 更多也是一套方便我们实现微服务的解决方案，也是一套框架体系 。

  • 微服务： 微服务是一种架构风格。

  • MVC 也是一种架构风格

  • DDD 是一种设计思想，可以在领域划分时帮我们决策。

  • 设计模式： 主要是编写代码时一些先辈们总结的一些经验之谈，是一些解决特定问题的模板或方法。

  • SOA ： SOA 是微服务架构风格出现之前的一种主流的架构设计风格。

  • 单体：单体是最早的软件架构风格。

  • MQ： MQ 更多是解决分布式消息传输的一套解决方案，是一种中间件，比如 kafka , rocketmq , rabbitmq 等等。

再看架构​

架构是一种为了解决某些关键问题而去做出的设计决策。

什么是架构师​

架构师（Architect）在软件工程领域中，类似与建筑学中的建筑师，负责软件项目的总计设计和规划。

架构师不仅要完成项目的整体设计，还要带领团队解决实际问题，攻克技术难点，确保软件的设计、开发、测试和发布流程顺利完成。

系统的生命周期​

  1. 业务分析
  2. 功能设计
  3. 代码编写
  4. 测试发布
  5. 线上观察

综合决策​

  1. 团队刚成立，需要指定标准的技术规范和统一的技术组件。
  2. 需要采集线上用户数据，实时 or 离线。
  3. 传统关系型存储无法解决业务痛点，是否需要升级存储设备。
  4. 业务发展迅速，如何保障服务的高效迭代和线上稳定性。

架构师能力图​

  • 制定技术路线，技术选型，系统优化，攻克技术难题。
  • 深入理解业务痛点，优化业务流程
  • 跨团队沟通，管理团队成员。

懂技术+懂业务+懂管理

架构师分类​

  • 后端架构师：微服务架构，容器化实战、开源框架技术、中间件技术、大型系统架构设计经验。

  • 数据架构师

  • 云平台架构师

  • 技术专家

  • 产品架构师

  • 安全架构师

架构设计应该由始至终​

需求分析阶段​

  • 识别出关键业务需求，非功能型需求。
  • 分析方案实现成本是否符合预期。

系统设计阶段​

在这个阶段，开发者将对系统进行详细的架构设计，包括模块划分、接口设计、数据流程设计等。

比如用户凭证存储在 本地内存还是 独立缓存服务，这就涉及到对后续系统发展的预判了。

系统开发阶段​

  • 在开发阶段中，开发者可以适当性地进行代码重构。
  • 在一些设计复杂调用链路环节，注重服务的依赖性是否合理。

系统使用阶段​

  • 在线上上线使用后，需要关注服务的 SLA（服务水平协议）。
  • 通过日志打印，异常记录，监控平台等手段监控系统运作健康情况。
  • 对一些研发流程进行梳理，分析是否存在潜在风险。

架构设计时应该考虑的因素​

业务理解​

  • 拆解功能型需求和非功能型需求。
  • 考虑业务后期的发展前景（具备行业经验更佳）
  • 前期开发阶段重视代码设计，减少技术债务。

技术标准化​

  • 单体架构 、 分布式架构 、 微服务架构、 事件驱动架构。
  • 架构的无状态性。
  • 标准的技术组件。

可维护性与稳定性​

  • 提前考虑后续可能遇到的非功能型问题，例如业务灵活变换，数据容量激增，流量激增，恶意攻击。
  • 考虑服务的稳定性，容错性、高可用性、可维护性。

安全性​

  • 敏感数据保护，例如手机号，身份证信息这类数据需要做加密存储，密钥需要做定期更换。
  • 保障系统链路安全性，例如 预防 SQL 注入攻击，Dos 攻击，Xss 攻击，核心交易接口被刷等风险问题。

后端服务架构演进​

系统的本质组成​

  • 业务： 脱离了业务做系统是在纸上谈兵，价值和收益并不大。
  • 逻辑控制： 和业务不挂钩的组件，比如 RPC 组件、 缓存、数据库

架构师关注业务和逻辑控制如何做更好的衔接，保证系统的可维护性、扩展性和性能。

演进趋势​

从混乱到有序： 将业务和逻辑控制的代码剥离的更清晰。将代码改造的更好维护。

放任不管，系统会逐渐变得混乱。

演进过程​

  1. 单体架构
  2. SOA 架构： SOA 架构风格更强调将一些基础的、公共的、可复用的能力抽象出来，通过事件总线和应用编排技术来组装成不同的业务流从而来达到的灵活高效的系统效果。
  3. 微服务架构：随着移动互联网的爆发， 对系统的灵活性、可扩展性要求越来越高，SOA 架构在灵活性方面存在一些问题。
  4. 无服务架构：开发者无需关注后端的容器化部署，云厂商帮忙屏蔽了细节。

技术使用门槛越来越低了。

单体架构​

初期代码架构混乱，MVC 是为了解决这一问题提出的，MVC 关注代码独立且分离，基于接口调用。

MVC 依旧存在高度耦合的情况，比如同级别的调用。

MVC 分层之后，又有人提出了模块化的架构，把一些业务共性的模块进行了整合。代码按业务模块划分。

模块化之后，还是存在问题，代码膨胀、性能瓶颈，风险系数高（模块与模块之间的资源占用不一样，用于影响其它模块）

事件驱动架构（EDA）​

利用事件总线进行消息传播

性能极佳，但是很难保证事务的一致性。

SOA 架构​

  • 强调复用底层系统的可复用能力做编排。
  • ESB 需要负责多个服务之间的协调，非常重。
  • 早些年 SOA 架构没有很易用的框架封装，大部分技术被 IBM，甲骨文这些公司垄断，收费昂贵。
  • 早些年使用 ESB 总线基本都是走 WebService 通信，协议复杂难懂。

微服务架构​

  • 按照业务领域划分独立服务模块，和 SOA 一样，也强调将一些公共的能力沉淀到下层，上游主要是做一些服务调用的之间的数据拼装。
  • 可基于容器化部署，灵活性高
  • 无共享，强调数据隔离性。
  • 技术难度大，对团队要求高（分布式事务、分布式缓存、分布式存储）
  • 服务规模会比单体架构要庞大很多。

无服务架构​

  • 屏蔽了底层的技术设施技术
  • 需要在调用方将各个云函数进行聚合。

数据架构设计​

  • 离线/实时数仓建设
  • 实时计算任务实战
  • 数据采集与分析
  • 用户画像
  • 社交+ 电商平台推荐系统实战