【非原创】微服务设计

以下内容来源美团点评 舒超 老师 在 InfoQ 关于微服务的直播；

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