所以微服务并不是适用于所有项目、所有团队的。在应用之前一定要搞清楚是否适合自己。
要保证这么一套微服务架构能成功运行起来，我们起码需要以下这些 微服务的基础组件：
- 服务注册
部署了一个微服务节点，得让调用者知道啊，当微服务节点有增加或减少的时候，也得让调用者及时知晓啊。这些问题都是通过“服务注册”组件来实现的，服务提供者将自己的服务地址等信息登记到“服务注册”组件中，调用者需要的时候，每次都先去查询“服务注册”即可。免去人工维护微服务节点的信息同步问题。
- 服务网关
是指提供给外部系统调用的是统一网关。主要做安全和权限控制等。
- 配置中心
微服务的配置中心是用来统一管理所有微服务节点的配置信息的。因为同一个程序可能要适用于多个环境，所以在微服务实践中要尽量做到程序与配置分离，将配置进行集中管理。包括微服务节点信息、程序运行时配置、变量配置、数据源配置、日志配置、版本配置等。
- 服务框架
是指用来规范各个微服务节点之间通信标准的。服务间通信采用什么协议、数据是如何传输的、数据格式是什么样的。有了这个统一的“服务框架”就能保证各个微服务节点之间高效率的协同。
- 服务监控
微服务运行起来之后，为了能够监控节点的健康情况，保障节点的高可行，需要对各个服务节点进行收集数据指标、然后对数据进行实时处理和分析，形成监控报表和预警。
- 服务追踪
一旦使用了微服务架构，那么当有请求过来时，就会经过多个微服务节点的处理，形成了一个调用链。为了进行问题追踪和故障的定位，需要对请求的完整调用链进行记录。
这里的服务追踪与上面的服务监控是不同维度的，一个是全局的，一个是微观的，发挥的作用也不一样。
- 服务治理
就是指需要通过准备一些策略和方案，来保障整个微服务架构在生产环境遇到极端情况下也能正常提供服务的措施。比如 熔断、限流、隔离等等。
当然，上述只是一个微服务架构最为核心的基础组件，一旦微服务体系过大，例如有几十上百个微服务节点，那么开发、维护、测试的成本就会非常大。因此一般还会引入 自动化部署 和 自动化测试 来提高协同效率。
三、「 微服务 」入门如何避免踩坑？
你以为微服务架构都是下面这样的吗？
事实上，更能是下面这样的，哈哈。
大家都在宣扬「 微服务 」多么多么的好，例如：易扩展、松耦合、服务简单、独立开发、易维护、轻量级等等。虽然这些优势也是事实，但是「 微服务 」带来的问题也很多，尤其是对于刚入门的团队而言，应用微服务后，趟坑真的可以趟到你崩溃。下面就普及一些常见的问题来给大家打个预防针：
- 不是所有项目都适用微服务
有些项目规模还比较小，或者项目才刚立项启动，也只有三四个人负责开发维护，这时候是不建议一上来就搞微服务架构的。这种情况下搞微服务，不仅是“杀鸡用牛刀”，而且还无谓的增加了项目的复杂度，本身一个单体结构就可以搞定的事情，非得拆分N多节点，人员又不足以支撑这么多节点的开发维护，这完全是自找苦吃。反而是等项目成熟了、规模大了之后，再开始慢慢将原有结构拆为微服务才是正确的做法。
- 不要拆分过多过细的服务
小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
最后总结
ActiveMQ+Kafka+RabbitMQ学习笔记PDF
关于分布式，限流+缓存+缓存，这三大技术（包含：ZooKeeper+Nginx+MongoDB+memcached+Redis+ActiveMQ+Kafka+RabbitMQ）等等。这些相关的面试也好，还有手写以及学习的笔记PDF，都是啃透分布式技术必不可少的宝藏。以上的每一个专题每一个小分类都有相关的介绍，并且小编也已经将其整理成PDF啦
（包含：ZooKeeper+Nginx+MongoDB+memcached+Redis+ActiveMQ+Kafka+RabbitMQ）等等。这些相关的面试也好，还有手写以及学习的笔记PDF，都是啃透分布式技术必不可少的宝藏。以上的每一个专题每一个小分类都有相关的介绍，并且小编也已经将其整理成PDF啦
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
