Java圈全能架构师的博客

先说背景 前段时间有个读者问我，他说他们的 RPC 框架用的是 Dubbo，当对接一个新服务的接口时就需要开通对应的网络关系。 比如我是 A 服务，第一次对接 B 服务的 Dubbo 接口，那么我需要开通 A 服务到 B 服务的对应的 Dubbo 端口的网络访问权限。 但是有的时候总是有人忘记开通网络权限，导致业务展开的时候服务调用报错。已经吃过几次这样的亏了。 目前他们想到的解决方案是 A 服务启动后就调用 B 服务提供的一个专门用于测试能否调通的接口。如果不通，配合监控手段，这样就能主动发现问题

这几年在 Java 工程师招聘时，会看到很多人的简历都写着使用了 Spring Cloud 做微服务实现，使用 Docker 做自动化部署，并且也会把这些做为自己的亮点。 而比较有趣的这其中以小公司出来的人为绝大多数，大的公司出来的人简历上倒是很少提这些东西。 对于我自己来说，从 2015 年就开始关注这一块，看过马丁·福勒最开始的关于微服务的论文、也看过不少对微服务的论证的英文文章和书，也研究过 Spring Cloud、Sofa 等开源实现以及 Service Mesh。 考虑到我们公司.

前言 微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。 企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中，微服务被认为是未来的方向。通过将应用和服务分解成更小的、松散耦合的组件，它们可以更加容易升级和扩展，理论上是这样。 什么是微服务架构 微服务是一种软件架构风格，目标是将一个复杂的应用拆分成多个服务模块，每个模块专注单一业务功能对外提供服务，并可以独立编译及部署，同时各模块