
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构是目前大多数Java编程开发程序员都在学习与应用的一个软件架构方式,下面我们就通过案例分析来简单了解一下,微服务架构可以解决哪些编程问题。
微服务架构是一种架构风格,整个应用被划分并设计为以业务域为模型的松散耦合的独立服务。微服务中的“微”非常具有欺骗性,事实上它没有规定服务的规模有多小或多大。
这里的重点是每个独立服务都有一个业务边界,可以独立开发、测试、部署、监控和扩展,甚至可以用不同的编程语言开发它们。
在基于微服务的架构中,每个组件或服务都有自己的数据库。没有集中式数据库,我们可以根据需要为每个单独的微服务使用NoSQL、RDBMS或任何其他数据库,这也是让微服务真正独立的原因之一。
难以扩展
一体化架构应用只能通过在负载均衡器后面放置整个应用程序的多个实例来进行水平扩展。如果应用中的特定服务需要扩展,则没有简单的选项。我们需要完整地扩展应用程序,这显然会造成不必要的资源浪费。
相比之下,基于微服务的应用程序允许我们根据需要独立扩展单个服务。
交付时间长
一体化架构在单个应用的任何部分/层中进行的任何更改都需要构建和部署整个应用程序。个人开发人员还需要下载整个应用程序代码来修复和测试,而不仅仅是受影响的模块,这就影响到了持续部署的效率。
而在微服务架构中,如果仅在一百个微服务中的一个中需要改变,则仅构建和部署改变的微服务,没有必要部署一切。我们甚至可以在短时间内多次部署。
应用复杂性
过去,随着应用规模的增长(功能、功能等),团队也会相应扩张,应用很快就就会变得复杂和交织在一起。随着不同的团队不断修改代码,维护模块化结构慢慢变得越来越困难,并慢慢导致像意大利面一样交织的代码。这不仅会影响代码质量,还会影响整个组织。
在基于微服务的应用中,每个团队都在单独的微服务上工作,代码会有序很多。
没有明确的所有权
在一体化应用中,看起来独立的团队实际上并不是独立的。它们同时在相同的代码库上工作,严重依赖于彼此。
在基于微服务的应用中,独立团队处理单独的微服务。一个团队将拥有一个完整的微服务。工作的明确所有权明确控制服务的一切,包括开发、部署和监控。
故障级联
如果没有正确设计,一体化交媾应用的一部分失败可能会级联并导致整个系统崩溃。
在基于微服务的架构的情况下,我们可以使用断路器来避免这种故障。
Dev和Ops之间的墙
开发团队通常会进行开发、测试,一旦部署,就会将维护和支持的所有权交给运维团队,应用此时与开发团队无关了,而运维团队需要努力在生产环境中支持一体化架构应用。
在基于微服务的应用中,团队的组织理解为“构建它、运行它”,开发团队继续在生产中拥有该应用。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。