【金秋打卡】第9天 构建微服务设计架构知识体系--单体架构演进存在的痛点

课程名称：海量数据高并发场景，构建Go+ES8企业级搜索微服务

课程章节：5-3

课程讲师：少林码僧

课程内容：

• 单体应用问题

  • 模块间的耦合度太高，一个模块出问题，可能导致整个服务都有问题

  • 构建部署慢，各个模块依赖严重，不同的模块的开发进度又不一样，往往需要等待依赖方开发完才能部署，维护成本高，不同模块的开发人员需要对其他模块有了解

  • 迭代进度难以统一，边界职责难以划分，协作开发成本高
    

• 单体架构和微服务架构的对比

  • 交付速度；微服务的交付速度更快，用户体验更好，项目越大越复杂，微服务的效果越好

  • 故障隔离范围：微服务独立运行，可以进行独立部署。出问题也可以独立处理，无需停止整个业务，或者对整个业务做回滚。可以对微服务进行等级划分，区分核心服务和非核心服务，进而采取不同的策略和资源倾斜。

  • 持续演进灵活度：微服务对架构演进更为友好。即使是重构，也只需对单个或者几个微服务进行重构，无需对整个业务服务进行重构

  • 沟通效率：团队规模小，缩小沟通差距，提高沟通效率

  • 技术栈选择:微服务只要有统一的通信机制比如grpc就可以调用，而无需关心实现语言。不同服务使用不同语言在微服务很常见。而单体架构的实现语言一开始就定好了。

  • 可扩展性：微服务架构，可以根据业务要求进行扩展和缩容。而单体架构很少对已经实现的代码进行删除

  • 对复杂问题分解难度：把复杂问题拆成不同的简单小服务

  • 产品创新复杂度：团队有更多的自助决策，更多的试错机会，更利于创新

• 单体架构如何发展到微服务

  • 对单体应用进行服务化拆分

  • 将单体应用中的本地调用抽象成单独的模块后变成远程调用

  • 服务化在很大程度上解决可单体应用的不断膨胀导致的问题
    

• 单体架构演进过程中遇到的困难

  • 拆分的边界在哪？应该怎么拆分？

  • 服务数量大幅度增长，给运维部署带来沉重的负担怎么办？

  • 这么多小服务，应该怎么管理？

• 服务管理

  • 服务注册：服务启动的时候通过某种机制，比如API向注册中心注册自己的信息

  • 服务发现：服务实例去服务中心去找已经注册的服务，然后调用服务

  • 服务剔除: 把服务从注册中心剔除，将不能调用了。服务和注册中心之间保持心跳检测，如果心跳多次检测失败，就按照机制剔除服务。
    

• 服务之间的通信

  • RESTful API 

  • gRPC 可以直接像调用本地方法一样调用

  • 消息队列，如果服务是异步化的，比如视频转换服务，就可以用队列来通信

• 如何追踪错误

  • 链路追踪

  • go中使用的比较多的是Jaeger
    

课程收获:

本节学习了单体应用的问题，并对微服务做了简介