第十周总结

用户头像
orchid9
关注
发布于: 2020 年 11 月 29 日

微服务架构-服务本身的设计、维护与治理

传统架构的问题

  • 编译部署困难

  • 代码分支管理复杂

  • 数据库连接耗尽

  • 新增业务困难

解决办法:

拆分,将模块独立部署,降低系统耦合性。

微服务框架需求

失效转移(Fail Over):

  • 对于大型网站的微服务而言,即使是很少访问的简单服务,也需要集群部署,同时微服务框

架还需要支持服务提供者的失效转移机制,以实现服务高可用。

负载均衡:

  • 对于集群部署的服务提供者,服务请求者可以使用加权轮询等手段访问,使服务提供者集群

实现负载均衡。

高效的远程通信:

  • 对于大型网站,核心服务每天的调用次数会达到数以亿计,如果没有高效的远程通信手段,

服务调用可能会成为整个系统性能的瓶颈。

对应用最少侵入:

  • 网站技术是为业务服务的,是否使用微服务需要根据业务发展规划,微服务也需要渐进式的

演化,甚至会出现反复,即使用了微服务后又退回到集中式部署,微服务框架需要支持这种

渐进式演化和反复。当然服务模块本身需要支持可集中式部署,也可分布式部署。

版本管理:

  • 为了应对快速变化的需求,服务版本升级不可避免,如果仅仅是服务实现升级,那么这种升

级对服务请求者而言是透明的,无需关注。但是如果服务的访问接口发生变化,就需要服务

请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护,

同时升级接口,而网站服务不可能中断,需要服务提供者先升级接口,并同时提供历史版本

的服务供请求者调用,当请求者访问接口升级后才可以关闭历史版本服务。



微服务框架架构

spring cloud架构图



Service Mesh 服务网格

Service Mesh 是一个基础设施层,用于处理服务间的通信,通常表现为一组轻量级网络

代理,他们与应用程序部署在一起,而对应用程序透明。



微服务架构落地策略和思路

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

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

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

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



微服务网关的技术架构



领域驱动设计

为什么需要DDD

很多项目的实际情况:

  • 用户或者产品经理的需求零零散散,不断变更。

  • 工程师在各处代码中寻找可以实现这些需求变更的代码,修修补补。

  • 软件只有需求分析,并没有真正的设计,系统没有一个统一的领域模型维持其内在的逻辑一

致性。

  • 功能特性并不是按照领域模型内在的逻辑设计,而是按照各色人等自己的主观想象设计。

项目时间一长,各种困难重重,需求不断延期,线上 bug 不断,管理者考虑是不是要推

倒重来,而程序员则考虑是不是要跑路。

DDD 战略设计

领域是一个组织所做的事情以及其包含的一切,通俗地说,就是组织的业务范围和做事方式,也是软件开发的目标范围。领域驱动设计就是从领域出发,分析领域内模型及其关系,进而设计软件系统的方法。

子域

领域是一个组织所做的事情以及其包含的一切。 这个范围就太大了,不知道该如何下手。所以通常的做法是把整个领域拆分成多个子域,比如用户、商品、订单、库存、物流、发票等。

限界上下文

在一个子域中,会创建一个概念上的领域边界,在这个边界中,任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和子域具有一对一的关系,用来控制子域的边界,保证子域内的概念统一性。通常限界上下文对应一个组件或者一个模块,或者一个微服务,一个子系统。



课后作业



用户头像

orchid9

关注

还未添加个人签名 2018.08.21 加入

还未添加个人简介

评论

发布
暂无评论
第十周总结