大家好,欢迎来到程序视点!我是小二哥。今天我们从微服务的架构说起!
微服务架构图谱,通过谷歌或Bing下,可以看到各种各样的架构图,源于业务和架构师自身的喜好或者粗细粒度。
就整体来说,每个架构图的基本组件和架构分层都差别不大,只是有的细一些,有的粗一下。比如有客户端层,容器层(K8S),API Gateway,微服务集群层,EventBus层是必须要有的,至于服务监控和服务跟踪、服务治理本身就是一个完整的系统,粒度就没有细了。
基于以上这些概念,这里给大家分享一个架构图。这里省去服务监控跟踪和治理的部分,后续单独抽离出来分析。
这边的架构图谱更加贴近业务,粒度也更细。
以上架构图主要分4层,每个层次遵循架构分层的核心思想:关注点分离,职责各异,边界清晰。
第1层:客户端:理论上包含一切可以联网的设备,包括移动设备,Android、IoS、Pad、微信、微博、QQ、Web、各自浏览器、物联网设备等等……
第2层:API网关:包括服务注册,发现,认证授权,单点登录,熔断,限流……网关的知识点丰富,是微服务的核心之一。
第3层:微服务集群:包括各种具体的microservice,比如纵向划分的业务服务(用户服务,订单服务,……),横向划分的基础或公共服务(元数据服务,公共服务……)
第4层:事件总线:Event Bus 目的是消息解耦,不要让服务之间直接的链接。不同与SOA的服务总线,事件总线相对比较轻量,经常基于消息队列引擎进行解耦,目的是为了让服务之间的关联弱化,不直接进行关联。很多时候用的是相对稳定、可靠、企业级的RabbitMQ。
微服务的架构其实不难,根据以上的架构,每种业务都可以进行套用,这里的难点在于服务的划分和粒度控制,另外如何管理膨胀的服务是一个麻烦事。
如何正确拆分微服务呢?这里正确指的是合理,因为没有绝对的标准。按照前人的经验可以分为纵向和横向两种划分方法:
① 纵向拆分
是从业务维度进行拆分。标准是按照业务的关联程度来决定,关联比较密切的业务适合拆分为一个微服务,而功能相对比较独立的业务适合单独拆分为一个微服务,比如上图中的订单服务,用户服务。另外粒度太小,服务聚合是一个坑,粒度太大,分和没分一个样。真的很需要经验!!!
② 横向拆分
是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用,且依赖的资源独立不与其他业务耦合。比如上图中的元数据服务和消息服务。
借用《微服务设计》中的一句话:“你越不了解一个领域,为服务找到合适的界限上下文就越难……服务的界限划分错误,可能会导致不得不频繁地更改服务间的协作,而这种更改成本更高……”
软件行业从业者,尤其是那些已经不写代码的从业者,总会期望有银弹,但银弹终究是没有的:微服务依赖于“基础设施自动化”,微服务不是“银弹”。
有关微服务的知识点非常的多。限于篇幅内容,今天先到这里。后续继续给大家分享更多的内容!