写点什么

微服务 /DDD - 第十周总结

用户头像
孙志平
关注
发布于: 2020 年 08 月 12 日

超大型单体应用存在的问题

  • 编译、部署困难:源代码过于庞大

  • 代码分支管理困难:功能开发过于交叉,导致合并代码冲突

  • 数据库连接池耗尽:分布式部署越多消耗越多

  • 新增业务困难



解决方案就是拆分,将模块独立部署,降低系统耦合性:

  • 纵向拆分:将一个大应用拆分为多个小应用,如果新增业务比较独立,那么就直接将其设计部署为一个独立的web应用系统。

  • 横向拆分:将复用的业务独立拆分出来,独立部署为微服务,新增业务只需要调用这些微服务即可。



微服务框架需求

  • 失效转移

对于大型网站的微服务而言,即使是很少访问的简单服务,也需要集群部署,同时微服务框架还需要支持服务提供者的失效转移机制,以实现服务高可用。

  • 负载均衡

对于集群部署的服务提供者,服务请求者可以使用加权轮询等手段访问,使服务提供者集群实现负载均衡。

  • 高效的远程通信

对于大型网站,核心服务每天的调用次数会达到数以亿计,如果没有高效的远程通信手段,服务调用可能会成为整个系统性能的瓶颈。

  • 对应用最少入侵

网站技术是为业务服务的,是否使用微服务需要根据业务发展规划,微服务也需要渐进式的演化,甚至会出现反复,即使用了微服务后又退回到集中式部署,微服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署,也可分布式部署。

  • 版本管理

为了应对快速变化的需求,服务版本升级不可避免,如果仅仅是服务实现升级,那么这种升级对服务请求者而言是透明的,无需关注。但是如果服务的访问接口发生变化,就需要服务请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护,同时升级接口,而网站服务不可能中断,需要服务提供者先升级接口,并同时提供历史版本的服务请求者调用,当请求者访问接口升级后才可以关闭历史版本服务。



微服务架构落地

  • 业务先行,先理顺业务边界和依赖,技术是手段而不是目的。

  • 现有独立的模块,后有分布式的服务。

  • 业务耦合严重,逻辑复杂多变的系统进行服务重构要谨慎。

  • 要搞清楚实施微服务的目的是什么,业务复用?开发边界清晰?分布式集群性能提升? 最终要的是为需求服务。



微服务核心问题

  1. 服务注册与发现

  2. 负载均衡

微服务部署后向注册中心注册,调用者通过注册中心获取服务列表,通过负载均衡算法选取一台进行微服务调用,调用者和微服务通过注册中心隔离,这样微服务增加与删除都不需要主动通知调用者。



微服务网关

微服务网关代替调用者与注册中心交互,调用者直接和网关通信,网关负载转发请求。



网关作用

  • 统一接入

  • 安全防护

  • 限流管控与容错

  • 协议适配



用户头像

孙志平

关注

还未添加个人签名 2018.05.08 加入

还未添加个人简介

评论

发布
暂无评论
微服务/DDD - 第十周总结