课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
随着互联网的不断发展,越来越多的软件开发架构方式被程序员掌握,下面我们就通过案例分析来了解一下,软件架构开发包含哪些结构层次。
基础服务层
基础服务层是一个抽象的概念。我们把提供基础业务处理能力的服务归类到这一层。我们按照模块\领域等概念把服务划分好,后建成了一个个独立部署的服务。它们提供一些基础的服务功能,对外提供一些api接口。每个服务都有自己独立的数据库,独立的运行时。每个服务都可以根据压力进行伸缩。这一层可以说是微服务架构里核心的一层。
聚合服务层
我们已经有了基础服务,为什么还会有聚合服务这一层呢。假设现在用户根据订单号查询订单明细的功能。这个功能可能需要涉及到订单基本信息、用户基本信息、会员信息、支付信息、房型信息等多个api。如果有前端直接调用基础服务层,那么可能要发送多次http请求。所以为了效率往往还需要有一个服务来聚合跟适配,合并成一次请求再对前端提供服务,这样对于前端来说效率相对会高一些,开发起来也简单很多。
再比如我们现在的系统往往会接入很多终端,有PC,有APP,有小程序。由于设备的不同,我们对外需要展示的内容也会有差异,我们可以在聚合层进行api的适配跟裁剪,根据不同的设备返回不同的响应。
网关
微服务网关在这个微服务架构中起着至关重要的的地位。从上面的图上可以看到,网关在架构的顶端,是流量的入口。它对每个一个请求进行监控,路由。使每一个合法的请求进入到对应的服务。
因为所有请求都会过网关,所以网关可以做一些全局的工作或者说类似AOP思想里切面的工作。比如认证、授权、限流、过滤等等。一旦网关服务崩溃往往会影响到整个微服务的工作,尽管它内部服务全部正常,但是它可能无法对外提供服务。
正因为网关所在的位置在架构中所承担的功能,所以我们需要网关组件的性能非常高,稳定性非常高。
常用的网关组件有:kong,zuul,Ocelot等。在.Net领域用的比较多的是Ocelot。
微服务相关组件
很多网上的架构图都把微服务相关的这些组件写到业务服务层下面,叫做支撑服务。其实个人是不太认同的。所谓支撑的话可以说是桌子的腿,少了一条桌子就会翻了。事实上我觉得一个完整的微服务不一定非要上全了所有组件。这种都是视情况而定的,没有绝对的说法。比如说不上监控服务,微服务就不能跑了吗?显然不是的。不是说上了这些组件就叫微服务,不上就不是微服务。有了日志聚合、服务发现等等组件是为了更好的实施微服务,但不是必须的,所以我并没有把他们叫做支撑服务。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。