对微服务项目架构的理解

对微服务项目架构的理解

常见微服务架构图

pc端和手机端来访问，在浏览器上面输入了一个域名显示了页面，这个请求给到了前端服务器，前端服务器主要是提供页面的展示。

之后调用负载均衡到达网关，为后端的微服务提供负载均衡的能力。

对微服务项目架构的理解

• 微服务间如何通信？REST API，RPC，MQ

• 微服务如何发现彼此？注册中心

• 组件之间怎么个调用关系？

• 哪个服务作为整个网站入口？前后端分离

• 哪些微服务需要对外访问？前端和微服务网关

• 微服务怎么部署？更新？扩容？

• 区分有状态应用与无状态应用

微服务之间通信

点对点：系统里面有很多微服务，这些微服务之间可以彼此通信，微服务都可以对外暴露接口，作为客户端可以直接访问任意一个服务，这些好处是更加自制了，对其他组件依赖少了，缺点如上。

点对点最佳实践是集群内部通过点对点。

通常来说微服务最佳实践就是点对点和api网官结合起来，外部有个客户端，要访问不同点内部服务，它的请求不会直接发到这个服务里面去，而是通过一个集中的api网关发起，这个客户端就直接将请求发到api网关，是一个集中的入口，在它的请求里面无论是通过header还是url来告诉api网关要访问哪个后端服务。那么这样的话api网关就可以将这个服务直接转到后端服务，这样api网关就可以做很多事情，比如说认证，比如说鉴权，比如说审计等，这些事情都可以在api网关当中集中去做掉。

请求给到后端的服务，那么微服务之间也有互相调用，那么它们之间可以互相调用，不要求每次调用都经过api网关。

为什么用注册中心系统

微服务太多面临的问题：

• 怎么记录一个微服务多个副本接口地址？

• 怎么实现一个微服务多个副本负载均衡？

• 怎么判断一个微服务副本是否可用？

主流注册中心：Eureka，Nacos，Consul

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。