微服务都是用在什么地方？能否举例说明一下
发布网友
发布时间：2022-04-19 14:23
共5个回答
热心网友
时间：2023-08-03 18:59
什么是微服务？
简单举例：一艘航空母舰作战能力虽然很强，但是弱点太明显，就是防御能力太差，单艘的航空母舰很少单独行动，通常航空母舰战斗群才是主要军事力量，你可以把单艘航母理解为的单体应用（防御差，机动性不好），把航母战斗群（调度复杂，维护费用高）理解为微服务。
大部分的开发者经历和开发过单体应用，无论是传统的 Servlet + JSP，还是 SSM，还是现在的 SpringBoot，它们都是单体应用，那么是什么问题，导致要抛弃单体应用转向微服务架构？主要问题如下：
部署成本高（无论是修改1行代码，还是10行代码，都要全量替换）
改动影响大，风险高（不论代码改动多小，成本都相同）
因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）
当然还有例如无法满足快速扩容，弹性伸缩，无法适应云环境特性等问题，都是微服务架构要解决的问题。
关于微服务的课程，建议您在B站搜索我们官方账号“尚学堂”进行学习！免费的课程哟！
希望能帮到您，望采纳！！
热心网友
时间：2023-08-03 18:59
什么是微服务架构？
微服务，作为云原生落地的重要技术架构之一，微服务实现了应用软件的模块化、组件化、共享化，实现了开发团队的化、小型化和协同化，为数字化应用研发创新更敏捷、更高效打下了坚实的基础。在云原生浪潮下，微服务架构不仅成为了主流的架构模式，而且在企业的应用中也占据了很大的地位，根据相关调查，未来将会有80%以上的工作负载会转移到微服务上。
微服务架构可以解决的问题
√ 实现传统架构向微服务架构无感转型
√ 有效减少研发团队重复“造轮子”
√ 结合DevOps实现研发创新提效
√ 减少业务运维难度与成本
微服务架构的优势
√ 业务能力组件化
√ IT能力标准化
√ 流程自动化
√ 服务能力SaaS化
热心网友
时间：2023-08-03 19:00
微服务架构的系统是一个分布式的系统，按业务进行划分为的服务单元，互不影响。
热心网友
时间：2023-08-03 19:00
最正宗的解释（维基百科的解释）：
微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。
微服务的起源是由 Peter Rodgers 博士于 2005 年度云计算博览会提出的微 Web 服务 (Micro-Web-Service) 开始，Juval Löwy 则是与他有类似的前导想法，将类别变成细粒服务 (granular services)，以作为 Microsoft 下一阶段的软件架构，其核心想法是让服务是由类似 Unix 管道的访问方式使用，而且复杂的服务背后是使用简单 URI 来开放接口，任何服务，任何细粒都能被开放 (exposed)。这个设计在 HP 的实验室被实现，具有改变复杂软件系统的强大力量。
2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小规模的集中管理 (例如 Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。
简单的理解：
微服务架构的系统是一个分布式的系统，按业务进行划分为的服务单元，解决单体系统的不足，同时也满足越来越复杂的业务需求。
相比于传统集中式的应用系统，微服务的优点：
每个服务存在，所以可以单独部署，不用每次发布某个功能都经历一次全服务发布。
遵循单一功能原则，服务之间可以通过RESTFUL或者RPC调用，功能解藕
“细粒度” 的高可扩展性，每个服务都可以单独扩展，单独负载均衡
去中心化，尽可能地实现 “自服务”
有利于简化单独的开发测试以及部署，对开发团队友好
微服务缺点：
服务的可用性和维护性高度依赖于服务治理，如果治理得不好将会是灾难
某些服务可能造成性能瓶颈，某些服务的宕机可能导致很多服务受影响
服务配置繁琐
热心网友
时间：2023-08-03 19:01
微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部进程所*。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。
