初识微服务
一.单体架构和微服务架构的比较
1.单体架构的优势和不足
单体架构的优势:在项目的初期便于开发、便于测试、便于部署
单体架构的不足:
- 复杂性高-代码难以理解,难以修改和重构
- 交付效率低-项目整体部署耗时长、难以定位问题、影响范围广、风险大、发布频次低
- 伸缩性差-单体只能按整体进行横向扩展,无法分模块垂直扩展;IO密集型模块(日志收集)和cpu密集型模块(图片压缩、加解密)无法独立扩容和升级
- 可靠性差-一个bug有可能引起整个应用的崩溃
- 受技术栈限制,团队只能使用同一个语言和框架
什么是横向扩展和垂直扩展?
1)横向扩展
也叫 水平扩展
,用更多的节点支撑更大量的请求。 如成千上万的蚂蚁完成一项搬运工作
2)纵向扩展
又叫 垂直扩展
,扩展一个点的能力支撑更大的请求。如利用1个人的能力,如蜘蛛侠逼停火
2.什么是微服务架构?
微服务架构本身来源于互联网的思路,因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。
将单体应用拆分成多个高内聚低耦合的小型服务,每个小型服务运行在独立进程当中,由不同的团队开发和维护,服务间采用轻量级通信机制,
独立自动部署,可以采用不同的语言以及存储。
3.微服务架构的优势
- 易于开发和维护-微服务相对小,易于理解,启动时间少,开发效率高
- 独立部署-一个微服务的修改不需要协调其他服务
- 伸缩性强-每个服务都可以进行横向和纵向扩展;每个服务都可以独立扩容
- 技术异构性-各个微服务可以使用最适合该服务的技术
二、微服务所要解决的主要问题
1.服务的拆分
- 微服务拆分的原则-高内聚低耦合、服务粒度适中
- 拥有独立的数据库
- 微服务之间确定服务边界
2.数据一致性
- 通信技术方案-RPCvsRESTvs异步消息
- 服务注册和发现
- 负载均衡
4.服务网关
- 身份认证、路由服务、流量控制、日志统计
- 为前端服务的后端
比如将多个服务的数据聚合在一起返回给前端
- 健康检查、集中监控
微服务整个系统都需要在我们的监控体系中,包括注册中心的监控、 服务进程的监控、流量的监控、日志的监控,状态的监控等
- 日志聚合及检索
比如说在电商app中,我们无法进行下单操作,在分布式服务架构中 ,日志是散落在多个服务上的,我们如果说登录每台服务器进行检索是非常低效的,这就需要我们进行日志格式的标准化,并利用一定的手段将日志聚合起来进行检索查询,我们需要将这些检索查询的组件放到共享库当中,或者代码脚手架进行提供,以方便我们和业务代码进行解耦。
- 分布式追踪
在微服务场景中,一个客户端发起的请求要经过多个服务的调用,我们不知道该请求经历哪些服务的调用,调用哪些服务出现了问题,每个服务的输入输出是什么,这都给我们定位问题带来的困难;除此之外如果一个请求耗时挺长,我们不知道哪个服务耗时最长,这就给我们性能优化带来了困难。随着架构的演进,我们需要知道服务之间的依赖关系,这就需要我们的分布式追踪。
6.可靠性
- 流量控制,超时控制
- 仓壁隔离,熔断机制
- 服务降级,幂等重试
三、SOA和微服务的比较
- 技术栈
SOA:ESB、SOAP
微服务:轻量级MQ、REST、RPC
- 数据拆分
SOA:共享数据库
微服务:一服务一数据库
- 服务粒度
SOA:服务粒度比较粗,多个单体的组合
微服务:粒度更小的服务
上一篇: 优化不易,且写且珍惜