初识微服务架构

标签：直接   精益   rip   难度   src   dock   修改   行业   成本   

软件架构的进化

什么是软件架构？

• 软件架构是在软件的内部，经过综合各种因素的考量
  、权衡，选择特定的技术，将系统划分成不同的部分并使这些部分相互分工，彼此协作，为用户提供需要的价值

  哪些因素？

1. 业务需求
2. 技术栈
3. 成本
4. 组织架构
5. 可扩展性

6. 可维护性

   什么是单体架构

• 定义：功能、业务集中在一个发布包你，部署运行在一个进程中。

  单体架构优势

• 易于开发
• 易于测试
• 易于部署

• 易于水平伸缩

  单体架构面临的挑战

• 代码膨胀，难以维护
• 构建、部署成本大
• 新手上手困难
• 创新困难

• 可扩展性差

综上所述 单体架构已经out了

什么是微服务

• 定义：使用一套下服务来开发单个应用的方式，每个服务运行
  在独立的进程里，一般采用轻量级的通讯
  机制互联，并且他们可以通过自动化的方式
  部署

  多微才算微？

• 代码量？
• 开发时间？

• 不可度量

  微服务的特征

1. 单一职责

• 比如订单一个服务，登录注册一个服务
• 两个关系不大的可以作为单个服务

1. 轻量级通信

• 微服务与微服务之间的通信 如rpc

1. 隔离性

• 独立部署 相互隔离

1. 有自己的数据
   - 业务的数据独立性，降低数据复杂度
2. 技术多样性

• 语言不限如java，go，python都行

  微服务诞生背景

• 互联网行业的快速发展
• 敏捷开发，精益方法深入人心

• 容器技术的成熟(docker使微服务架构落地成为可能)

画一个传统架构图

画一个微服务架构图

• 假定业务场景

1. 一个在线教育的网站部分功能
2. 用户可以登录注册，获取用户信息
3. 有发送邮件发送短信的功能
4. 可以查看课程列表和对课程的CRUD

微服务架构的优势

• 独立性

1. 独立部署，相互隔离，但微应用出问题不影响其他服务

• 敏捷性

1. 技术栈灵活
2. 高效团队

微服务架构的不足

• 额外的工作

1. 服务的拆分

• 数据一致性

1. 在单体应用中 数据库使用的同一个，数据很好保持一致性，
2. 在微应用中心 由于都是需要分库分表的在这种模式下，可能对数据库的一致性有难度
3. 沟通成本
4. 在单体应用中 如想修改某个接口，就可以直接修改了，
5. 在微应用中 可能这个接口不是你负责的 或者不能你们组负责的这就需要去和负责的人沟通了

初识微服务架构

标签：直接   精益   rip   难度   src   dock   修改   行业   成本   

原文地址：https://www.cnblogs.com/guigujun/p/10017892.html