微服务 /DDD - 第十周总结
超大型单体应用存在的问题
编译、部署困难:源代码过于庞大
代码分支管理困难:功能开发过于交叉,导致合并代码冲突
数据库连接池耗尽:分布式部署越多消耗越多
新增业务困难
解决方案就是拆分,将模块独立部署,降低系统耦合性:
纵向拆分:将一个大应用拆分为多个小应用,如果新增业务比较独立,那么就直接将其设计部署为一个独立的web应用系统。
横向拆分:将复用的业务独立拆分出来,独立部署为微服务,新增业务只需要调用这些微服务即可。
微服务框架需求
失效转移
对于大型网站的微服务而言,即使是很少访问的简单服务,也需要集群部署,同时微服务框架还需要支持服务提供者的失效转移机制,以实现服务高可用。
负载均衡
对于集群部署的服务提供者,服务请求者可以使用加权轮询等手段访问,使服务提供者集群实现负载均衡。
高效的远程通信
对于大型网站,核心服务每天的调用次数会达到数以亿计,如果没有高效的远程通信手段,服务调用可能会成为整个系统性能的瓶颈。
对应用最少入侵
网站技术是为业务服务的,是否使用微服务需要根据业务发展规划,微服务也需要渐进式的演化,甚至会出现反复,即使用了微服务后又退回到集中式部署,微服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署,也可分布式部署。
版本管理
为了应对快速变化的需求,服务版本升级不可避免,如果仅仅是服务实现升级,那么这种升级对服务请求者而言是透明的,无需关注。但是如果服务的访问接口发生变化,就需要服务请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护,同时升级接口,而网站服务不可能中断,需要服务提供者先升级接口,并同时提供历史版本的服务请求者调用,当请求者访问接口升级后才可以关闭历史版本服务。
微服务架构落地
业务先行,先理顺业务边界和依赖,技术是手段而不是目的。
现有独立的模块,后有分布式的服务。
业务耦合严重,逻辑复杂多变的系统进行服务重构要谨慎。
要搞清楚实施微服务的目的是什么,业务复用?开发边界清晰?分布式集群性能提升? 最终要的是为需求服务。
微服务核心问题
服务注册与发现
负载均衡
微服务部署后向注册中心注册,调用者通过注册中心获取服务列表,通过负载均衡算法选取一台进行微服务调用,调用者和微服务通过注册中心隔离,这样微服务增加与删除都不需要主动通知调用者。
微服务网关
微服务网关代替调用者与注册中心交互,调用者直接和网关通信,网关负载转发请求。
网关作用
统一接入
安全防护
限流管控与容错
协议适配
评论