课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构设计随着互联网的不断发展而被众多程序员掌握,目前许多软件开发项目也都采用了微服务设计等技术,而本文我们就通过案例分析来简单了解一下,微服务架构设计实践需要解决哪些问题。
1)设计微服务之间的依赖关系
一个合理的分布式系统,系统之间的依赖应该是非常清晰地。依赖,在软件开发中指的是一个应用或者组件需要另外一个组件提供必要的功能才能正常工作。因此被依赖的组件是不知道依赖它的应用的,换句话说,被调用者不需要知道调用方的信息,否则这不是一个合理的依赖
在微服务设计时,如果domainservice需要通过一个from参数,根据不同的渠道做出不同的行为,这对系统的拓展是致命的。例如,用户服务对于访问他的来源不应该知晓;用户服务应该对订单、商品、物流等访问者提供无差别的服务。
因此,微服务的依赖关系可以总结为:上游系统不需要知道下游系统信息,否则请重新审视系统架构。
2)设计微服务间集成方式
拆分微服务是为了更好的集成到一起,对于后续落地来说,还有服务集成这一重要的阶段。
微服务之间的集成方式会受到很多因素的制约,前面在讨论微服务到底有多微的时候就顺便提到了集成会带来成本,处于不同的目的可以采用不同的集成方式。
采用RPC(远程调用)的方式集成。
使用RPC的方式可以让开发者非常容易的切换到分布式系统开发中来,但是RPC的耦合性依然很高,同时需要对RPC平台依赖。业界优秀的RPC框架有dubbo、Grpc、thrift等
采用消息的方式集成。
使用消息的方式异步传输数据,服务之间使用发布-订阅的方式交互。另外一种思想是通过对系统事件传递,因此产生了EventSourcing这种集成模式,让微服务具备天然的弹性。
采用RESTful方式集成。
RESTful是一种大化利用HTTP协议的API设计方式,服务之间通过HTTPAPI集成。这种方式让耦合变得极低,甚至稍作修改就可以暴露给外部系统使用。
这三种集成方式耦合程度由高到低,适用于不同的场景,需要根据实际情况选择,甚至在系统中可能同时存在。
服务间集成的方式还有其他方式,一般来说,上面三种微服务集成的方式可以概括目前常见系统大部分需求。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。