软件系统架构简述

单体架构

单体架构也称为单体系统，它就是把所有功能，所有模块都耦合在一个系统里面，它部署打包为一个独立单元（例如打包为jar或war），它最大的特点就是整套系统只有一个进程

不足

• 测试、部署成本高
• 可伸缩性差
• 可靠性差
• 迭代困难
• 技术栈单一，灵活性不够
• 整个系统一个团队，如果系统变得庞大，成员就需要学习大量的代码和领域知识，团队内的沟通和协作也变得低效

微服务架构

设计原则

• 按照业务能力（business capabilities）来规划或拆微服务
• 按照领域驱动设计（Domain-Driven Design，DDD）来规划或拆解微服务
• 微服务的设计应该遵循「单一职责」原则
• 微服务的设计应该遵循「高内聚」原则
• 微服务的设计应该遵循「低耦合」原则
• 服务无状态
• 服务高可用
  • 接入高可用中间件（如 sentinal)，实现限流、熔断、降级，增强可用性
• 服务可观测
  • 除了默认系统监控外，微服务需要梳理并定义必要的「业务监控指标」
• 服务配置可管理
  • 微服务相关配置需要统一接入配置中心进行管理、控制
• 避免「分布式大单体」
  • 只做单向调用，避免多个服务循环依赖调用形成集中式 “分布式大单体”，违背微服务的原则
• 异步解耦
  • 需接入消息队列，实现「依赖解耦」、「流量削峰」
• 服务发布遵循安全发布三板斧
• 正视「架构腐化」，遵循「持续演进」原则
  • 出现「频繁代码冲突」，影响快速迭代，那么这个微服务就需要拆分了
• 参考「AKF 扩展立方」模型，服务除了「水平扩容」外，还可以考虑「功能拆分」或者 「数据分区」
• 对于「废弃服务」，需要做好「下线」工作，包括服务下线、存储释放等

常见问题

• 为什么要使用微服务