软件架构的进化
什么是软件架构？
- 软件架构是在软件的内部，经过
综合各种因素的考量
、权衡，选择特定的技术，将系统划分成不同的部分并使这些部分相互分工，彼此协作，为用户提供需要的价值
哪些因素？
- 业务需求
- 技术栈
- 成本
- 组织架构
- 可扩展性
- 可维护性
什么是单体架构
- 定义：功能、业务集中在一个发布包你，部署运行在一个进程中。
单体架构优势
- 易于开发
- 易于测试
- 易于部署
- 易于水平伸缩
单体架构面临的挑战
- 代码膨胀，难以维护
- 构建、部署成本大
- 新手上手困难
- 创新困难
- 可扩展性差
综上所述 单体架构已经out了
什么是微服务
- 定义：使用一套下服务来开发单个应用的方式，每个服务运行
在独立的进程里，一般采用轻量级的通讯
机制互联，并且他们可以通过自动化的方式
部署
多微才算微？
- 代码量？
- 开发时间？
- 不可度量
微服务的特征
- 单一职责
- 比如订单一个服务，登录注册一个服务
- 两个关系不大的可以作为单个服务
- 轻量级通信
- 微服务与微服务之间的通信 如rpc
- 隔离性
- 独立部署 相互隔离
- 有自己的数据
- 业务的数据独立性，降低数据复杂度 - 技术多样性
- 语言不限如java，go，python都行
微服务诞生背景
- 互联网行业的快速发展
- 敏捷开发，精益方法深入人心
- 容器技术的成熟(docker使微服务架构落地成为可能)
画一个传统架构图
单体架构图.png
画一个微服务架构图
- 假定业务场景
- 一个在线教育的网站部分功能
- 用户可以登录注册，获取用户信息
- 有发送邮件发送短信的功能
- 可以查看课程列表和对课程的CRUD
微服务架构.png
微服务架构的优势
- 独立性
- 独立部署，相互隔离，但微应用出问题不影响其他服务
- 敏捷性
- 技术栈灵活
- 高效团队
微服务架构的不足
- 额外的工作
- 服务的拆分
- 数据一致性
- 在单体应用中 数据库使用的同一个，数据很好保持一致性，
- 在微应用中心 由于都是需要分库分表的在这种模式下，可能对数据库的一致性有难度
- 沟通成本
- 在单体应用中 如想修改某个接口，就可以直接修改了，
- 在微应用中 可能这个接口不是你负责的 或者不能你们组负责的这就需要去和负责的人沟通了
网友评论