微服务设计

发布于: 19 小时前

1、微服务解决哪些传统架构问题?

微服务作为一种【软件设计模式】,或者架构风格,将传统单体架构拆分为多个服务,以达到各个服务之间【高内聚低耦合】

2、微服务有哪些优势?

从技术角度:

(1) 快速持续集成/持续交付;

(2) 减少出BUG的概率,因为每个服务只关注一块业务或功能,比起单体架构代码量少;

(3) 微服务可以独立扩展资源,按【各自服务的性能要求】申请机器;

(4) 服务之间因为隔离,减小损失;比如 收货地址 服务出现问题,不影响订单服务;

从业务角度:

(1) 提高产品迭代,快速抢占市场;

(2) 业务稳定;

(3) 提升用户体验;

(4) 员工满意

从团队自身:

(1) 团队研发效率提升,一个团队只需要关注相关业务;

(2) 员工满意度提升,自由迭代,团队凝聚力变高;

3、微服务带来的问题

(1) 拆分的范围?该怎么拆?拆的粒度没有把控好,很可能导致团队分工不平衡;

(2) 拆分后,分布式通信产生的网络问题,不可靠性变高;

(3) 开发,测试,运维 效率较低,开发需要梳理下游接口,如果下游接口改变,会导致依赖服务都要改变;

(4) 组织协调问题变多,微服务多,沟通成本增加,需要跨多个团队协助配合;

4、不适合微服务?

(1) 初创团队,成本高;

(2) 不了解微服务,不能把握拆分的粒度,以及微服务相关的一整套服务治理;

5、拆分的原则/粒度

(1) 没有银弹;

(2) 目前还没有好的设计原则;

(3) 需要依赖主观判断;

(4) 方法论: A-以业务功能拆分;B-利用DDD思想划分子域,及子域之外的上下文;C-面向对象设计原则,闭包,单一职责;

(5) 拆分好坏取决于架构师能力;

(6) 经验;

如外卖为例,涉及的角色包括 商家,消费者,平台/骑手,商家、消费者和骑手的信息都可以单独拆一个服务,这是按职能/功能划分;

另外,还有 订单、记账、积分/评论、地图规划等服务;

6、微服务需要关注的基础设施

(1) 命名服务,服务的注册于发现,快速感知;参考:https://tech.meituan.com/2020/05/14/octo-mns-2.0.html

(2) 服务路由机制,服务增多,如何保证路由;同机房,用户取模;权重;

(3) 服务容错,如 熔断,限流,动态配置,以达到高可用;

(4) 服务监控,指标监控,包括系统和业务;

(5) 服务追踪,动态链路追踪,节点变多;

(6) 每次上线更新的代码检查;每个微服务的更新,不能影响上游,可以引用 灰度发布,A/B Test机制;

7、微服务稳定性保障的关键因素

(1) 事前预防,防止故障发生,还有立项时的可行性评估,系统的鲁棒性,如:

  • 访问容量,并发请求,数据大小;

  • 依赖方的SLA;

  • 对外的性能;

  • 需要增加额外的冗余;

  • 无状态的机器;

从研发角度,代码的PR/CR,压测,单元测试覆盖率等;

(2) 事中需要快速定位问题(最好最快的方式就是 重启服务!!!

  • 历史上曾经发生的问题,需要总结沉淀,经常复原问题,如 ES出问题的解决;

  • 28原则,用在性价比高的地方;

  • 故障演练,是否有效;

  • 断电演练,无通知演练,定期演练;提升研发的危机感,响应效率,系统的抗灾能力;

  • 查看依赖组件是否有演变,版本升级,服务升级;

  • 要有成熟的监控体系,故障信息可读性,可观测,打点数据上报;埋点指标,日志中心 -> ES -> 搜索;

(3) 事后止损降级,维护故障预案

  • 节点降级

  • 限流降级

  • 容错降级,服务端返回错误code,客户端熔断;

参考文档

https://tech.meituan.com/2020/05/14/octo-mns-2.0.html

https://www.cnblogs.com/xishuai/p/microservices-and-service-mesh.html

发布于: 19 小时前 阅读数: 7
用户头像

Albert

关注

还未添加个人签名 2018.08.31 加入

还未添加个人简介

评论

发布
暂无评论
微服务设计