7,765
社区成员
发帖
与我相关
我的任务
分享推荐一款.net Core 的微服务框架 JiMu
https://blog.csdn.net/zhengjian1996/article/details/113178804
...全文
请发表友善的回复…
发表回复
郑剑1996 2021-01-27
- 打赏
- 举报
grissom007大神已经为这个框架做了大量的处理,如果想用微服务可以直接从nuget上面引用依赖直接按照微服务的方式开发就行.如果想学习微服务,那么这是个很好的框架.正如框架名称一样jimu积木使用微服务就像搭积木那样简单,只需要简单的配置就能让项目变成微服务架构.如果想开发自己的模块,也可以按照约定写出模块,放到框架下面,引用后直接使用.当然如果对微服务不感兴趣,那grissom007大神在里面涉及的其他知识也是很好的学习素材
郑剑1996 2021-01-27
- 打赏
- 举报
关注我，后续我会写一些文章来详细解析这个框架。我们现在使用这个框架上开发环境，从开发到部署都提升了很多。白嫖社区这么多年知识，想回馈社区。加上近几年.net 社区活跃度比较低,跨平台的.net core 才发展几年,所以希望大家都能转到.net core 上面来,而不是转羡慕java或者转到java上面
郑剑1996 2021-01-27
- 打赏
- 举报
微服务架构已经流行了很长时间，但是想要回答为什么要使用微服务架构的问题，首先应该了解一体化架构。
什么是一体化架构？
一体化架构顾名思义，将应用各层打成一个包来部署。为了让代码正常工作，一体化应用的所有组件缺一不可。
以典型的3层传统web应用为例，该应用由用户界面、数据库、服务器端应用组成。这里的服务器端应用被称为monolith（一体化），包含表现、业务层、数据层。所有代码都存在于同一个代码库中。为了让代码工作起来，它被部署成为一个单元。任何一个小的改动变化，都需要重新构建和部署整个应用。
什么是微服务架构？
微服务架构是一种架构风格，整个应用被划分并设计为以业务域为模型的松散耦合的独立服务。微服务中的“微”非常具有欺骗性，事实上它没有规定服务的规模有多小或多大。
这里的重点是每个独立服务都有一个业务边界，可以独立开发、测试、部署、监控和扩展，甚至可以用不同的编程语言开发它们。
在基于微服务的架构中，每个组件或服务都有自己的数据库。没有集中式数据库，我们可以根据需要为每个单独的微服务使用NoSQL、RDBMS或任何其他数据库，这也是让微服务真正独立的原因之一。
一体化架构的问题
或者说是微服务架构所解决的问题。
1.难以扩展
一体化架构应用只能通过在负载均衡器后面放置整个应用程序的多个实例来进行水平扩展。如果应用中的特定服务需要扩展，则没有简单的选项。我们需要完整地扩展应用程序，这显然会造成不必要的资源浪费。
相比之下，基于微服务的应用程序允许我们根据需要独立扩展单个服务。在上图中，如果需要缩放服务B，则可以有10个实例，同时保持其他实例，并可以根据需要随时更改。
2.交付时间长
一体化架构在单个应用的任何部分/层中进行的任何更改都需要构建和部署整个应用程序。个人开发人员还需要下载整个应用程序代码来修复和测试，而不仅仅是受影响的模块，这就影响到了持续部署的效率。
而在微服务架构中，如果仅在一百个微服务中的一个中需要改变，则仅构建和部署改变的微服务，没有必要部署一切。我们甚至可以在短时间内多次部署。
3.应用复杂性
过去，随着应用规模的增长（功能、功能等），团队也会相应扩张，应用很快就就会变得复杂和交织在一起。随着不同的团队不断修改代码，维护模块化结构慢慢变得越来越困难，并慢慢导致像意大利面一样交织的代码。这不仅会影响代码质量，还会影响整个组织。
在基于微服务的应用中，每个团队都在单独的微服务上工作，代码会有序很多。
4.没有明确的所有权
在一体化应用中，看起来独立的团队实际上并不是独立的。它们同时在相同的代码库上工作，严重依赖于彼此。
在基于微服务的应用中，独立团队处理单独的微服务。一个团队将拥有一个完整的微服务。工作的明确所有权明确控制服务的一切，包括开发、部署和监控。
5.故障级联
如果没有正确设计，一体化交媾应用的一部分失败可能会级联并导致整个系统崩溃。
在基于微服务的架构的情况下，我们可以使用断路器来避免这种故障。
6.Dev和Ops之间的墙
开发团队通常会进行开发、测试，一旦部署，就会将维护和支持的所有权交给运维团队，应用此时与开发团队无关了，而运维团队需要努力在生产环境中支持一体化架构应用。
在基于微服务的应用中，团队的组织理解为“构建它、运行它”，开发团队继续在生产中拥有该应用。
7.陷入某种技术/语言
使用一体化架构，意味着被某种已实现的技术/语言锁定。如果需要更改技术/语言，则必须重写整个应用程序。
使用微服务，每个服务可以根据需求和业务以不同的技术或语言实现。任何改变服务技术/语言的决定都只需要重写该特定服务，因为所有微服务都是相互独立的。
8.支持微服务的正确工具/技术的可用性
几年前，我们还没有适当的工具和技术来支持微服务。但自从Docker容器和云基础设施（特别是PaaS）向大众提供服务以来，微服务正在大规模采用，因为它们提供了我们所需的“自由”，而无需进行传统的配置程序。
小结
简单来说，使用微服务架构会获得以下好处：
独立开发部署服务
速度和敏捷性
更高的代码质量
获得围绕业务功能创建/组织的代码
提高生产力
更容易扩展
自由（在某种程度上）选择实施技术/语言
https://www.sohu.com/a/251586213_515888
jhdxhj 2021-01-27
- 打赏
- 举报
您好，您的回复不是用不用框架的问题，这种场景单体架构从开发效率、部署难度等多方面都优于微服务架构，您可以了解下微服务的架构解决的问题。准确的说微服务并不适合您说的这种场景。它比较适合大规模、高并发的系统场景[/quote]
大规模，高并发的场景，如果国内的大厂不用这个，如何证明这个框架适合大规模，高并发？如何证明这个框架在大规模，高并发的场景下是稳定的？
晨易夕 2021-01-27
- 打赏
- 举报
为什么推荐？
优劣，对比，案例，都说说呗。
郑剑1996 2021-01-27
- 打赏
- 举报
您好，您的回复不是用不用框架的问题，这种场景单体架构从开发效率、部署难度等多方面都优于微服务架构，您可以了解下微服务的架构解决的问题。准确的说微服务并不适合您说的这种场景。它比较适合大规模、高并发的系统场景
jhdxhj 2021-01-27
- 打赏
- 举报
那为什么要用这个框架呢？如果只是简单的管理系统，就那么几十个用户，用这个框架意义何在？
郑剑1996 2021-01-27
- 打赏
- 举报
新的框架还没有大厂使用吧，稳定运行，文档不多
jhdxhj 2021-01-27
- 打赏
- 举报
这个框架国内哪些哪些大厂在使用？运行稳定不?文档多吗？
郑剑1996 2021-01-27
- 打赏
- 举报
如果用这个框架踩坑了，文档又少，怎么解决？ 这是很现实的问题，JAVA的微服务很多公司用的原因是很多大厂在使用，已经验证了其可以支撑大数据量和高并发[/quote]
如果用这个框架踩坑了，文档又少，怎么解决？ 这是很现实的问题，JAVA的微服务很多公司用的原因是很多大厂在使用，已经验证了其可以支撑大数据量和高并发[/quote]
如果用这个框架踩坑了，文档又少，怎么解决？ 这是很现实的问题，JAVA的微服务很多公司用的原因是很多大厂在使用，已经验证了其可以支撑大数据量和高并发[/quote]
可以先当做学习的框架,自己搞一套微服务上生产环境
jhdxhj 2021-01-27
- 打赏
- 举报
如果用这个框架踩坑了，文档又少，怎么解决？ 这是很现实的问题，JAVA的微服务很多公司用的原因是很多大厂在使用，已经验证了其可以支撑大数据量和高并发
