本文深入探讨微服务的实现，从微服务入门到服务通讯、发现、更新和部署，以及SpringBoot、SpringCloud和Dubbo在微服务周边的应用。介绍了Docker和Kubernetes在服务编排中的角色，强调了无代理通讯模式的优缺点，并分析了服务治理和负载均衡的重要性。最后，讨论了微服务开发中的服务器划分、RPC通讯和跨语言调用策略。
博主昵称：跳楼梯企鹅
博主主页面链接：博主主页传送门博主专栏页面连接：专栏传送门--网路安全技术
创作初心：本博客的初心为与技术朋友们相互交流，每个人的技术都存在短板，博主也是一样，虚心求教，希望各位技术友给予指导。
博主座右铭：发现光，追随光，成为光，散发光;
博主研究方向：渗透测试、机器学习 ;
博主寄语：感谢各位技术友的支持，您的支持就是我前进的动力 ;
目录
前三部分前面写文章已经分享过了，今天接着继续讲解
前三部分点击链接请点击此处，跳转前三部分
四、微服务器入门
1.微服务器入门
微服务就是由一系列围绕自己也为开发的微小服务构成，他们独立部署运行在自己的进程里，基于分布式的管理。（通俗定义：微服务是一种架构，这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机、同一个系统或同一个应用服务器中。）
2.优势劣势
（1）单体应用
（1）优点
单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。
（2）缺点
应用随着时间的推进，加入的功能越来越多，最终会变得巨大，一个项目中很有可能数百万行代码，互相之间繁琐的jar包；
久而久之，开发效率低，代码维护困难；
还有一个如果想整体应用采用新的技术，新的框架或者语言，那是不可能的；
任意模块的漏洞或者错误都会影响整个应用，降低系统的可靠性。
（2）微服务架构应用
（1）优点：
将服务拆分成多个单一职责的小的服务，进行单独部署，服务之间通过网络进行通信；
每个服务应该有自己单独的管理团队，高度自治；
服务各自有自己单独的职责，服务之间松耦合，避免因一个模块的问题导致服务崩溃
（2）缺点
开发人员要处理分布式系统的复杂性；
多服务运维 难度随着服务的增加，运维的压力也在增大；
服务治理和服务监控关键；
3.如何通讯
无代理模式
在这里，我们使微服务直接相互通信。你可以使用 HTTP 进行传统的请求响应，也可以使用 websocket（或 HTTP2）进行流式传输。
两个或多个微服务之间绝对没有中间节点（路由器和负载均衡器除外）。你可以直接连接到任何服务，只要你知道它们的服务地址和它们使用的 API。
听起来很基础，对吗？差不多是。有一些很棒的协议，例如 GRPC，可以使生活更加轻松。
优点：
- 低延迟：此方法具有最低的延迟。这里没有代理，因此它很快。施加的限制主要是由于不良的 API 实现。但是同样，GRPC 之类的工具可确保您在 API 层获得最佳性能。
- 易于实施：无代理的设计易于可视化和实施。这使生活变得更加轻松，世界变得更加幸福。
- 易于调试：这种方法非常易于调试，尤其是在我要讨论的下一个方法中。在分布式系统中，调试或跟踪错误所在的位置非常重要。一天多次发布新版本时，这一点变得尤为重要。
- 高吞吐量：在这种机制中，实际上是在工作而不是路由上花费了更多的CPU。现在可能还不那么明显，但是有代理的设计会使这一点更加清楚。大多数数据库 API 实际上使用无代理设计也就不足为奇了。
缺点：
- 服务发现：在这种设计中，服务发现至关重要。服务发现机制需要具有足够的响应能力和可伸缩性，以反映集群的最新状态。
- 连接噩梦：想象一下所有微服务需要相互连接，那将有很多联系。这些连接大多数都是相当空闲的。结果，浪费了很多资源。
- 紧耦合：从本质上讲，无代理设计是紧耦合的。假设您有一个微服务来处理在线支付，现在您希望另一个微服务能够为您提供每分钟发生的付款数量的实时更新。这将需要您在多个微服务中进行修改，这是不希望的。
在许多情况下，无代理的设计是行不通的。您通常需要简单地发布一次消息，并让多个订阅者消费它。这就是代理模式。
最低0.47元/天 解锁文章
1755
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
