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