目录

服务架构演变

单体架构

分布式架构

分布式架构要考虑的问题

微服务

初步认识

案例Demo

服务拆分注意事项

服务拆分示例

服务调用

---

• 服务架构演变

• 单体架构

  • 将业务的所有功能集中在一个项目中开发，打成一个包部署
• 优点：
  • 架构简单
  • 部署成本低
• 缺点：
  • 耦合度高
  • 扩展性差(维护困难、升级困难)适合小型项目

• 分布式架构

• 根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务
• 优点：
  • 降低服务耦合
  • 有利于服务升级拓展
• 缺点：
  • 服务调用关系错综复杂，架构复杂，难度大；适合大型互联网项目

• 分布式架构要考虑的问题

• 服务拆分粒度如何？
• 服务集群地址如何维护？
• 服务之间如何实现远程调用？
• 服务健康状态如何感知？

• 微服务

• 微服务是一种经过良好架构设计的分布式架构方案
• 优点：
  • 拆分粒度更小、服务更独立、耦合度更低
• 缺点：
  • 架构非常复杂，运维、监控、部署难度提高
• 微服务的架构特征：
• 单一职责：
  • 微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
• 自治：
  • 团队独立、技术独立、数据独立，独立部署和交付
• 面向服务：
  • 对外暴露业务接口
• 隔离性强：
  • 服务调用做好隔离、容错、降级，避免出现级联问题

• 初步认识

• SpringCloud是目前国内使用最广泛的微服务框架
• 它集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验

  

• Dubbo，SpringCloud，SpringCloudAlibaba技术对比

  

• 案例Demo

• 服务拆分注意事项

• 1.不同微服务，不要重复开发相同业务
• 2.微服务数据独立，不要访问其它微服务的数据库
• 3.微服务可以将自己的业务暴露为接口，供其它微服务调用

• 服务拆分示例

• cloud-demo：父工程，管理依赖
  • order-service：订单微服务，负责订单相关业务

    

  • user-service：用户微服务，负责用户相关业务

    

• 服务调用

• 修改order-service中的根据id查询订单业务，要求在查询订单的同时，根据订单中包含的userId查询出用户信息，一起返回
• 在order-service中向user-service发起一个http的请求，调用http://localhost:8081/user/{userId}接口
• 1.注册RestTemplate的实例到Spring容器

  

• 2.修改order-service服务中的queryOrderById方法

  

• 3.测试成功
• 
• 
• 即基于RestTemplate发起的http请求实现远程调用
• http请求做远程调用是与语言无关的调用，只要知道对方的ip、端口、接口路径、请求参数即可