浅谈微服务架构与.Net Core

微服务(microservice)这个概念是2012年出现的,2014年3月Martin Fowler在他的个人网站(https://martinfowler.com/articles/microservices.html)中是这样说到的:

The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.

微服务架构”一词在过去几年中兴起,描述的是将软件应用程序设计为可独立部署服务套件的特定方式。虽然没有对这种架构风格的精确定义,但其具有一些共同的特性,如围绕业务能力自动化部署、智能端点、对语言及数据的“去集中化”控制等等。

通俗的讲,我们可以这样认为:传统系统的开发,我们将整个系统分为表示层、服务层、业务逻辑层、数据访问层进行开发,但最终我们将这所有的代码编译在一起发布,这样做也有它的优点,比如开发简单、不存在分布式管理,但这样也有缺点,比如:一个小的bug可能导致整个应用程序的崩溃、系统业务之间代码耦合度高不易于维护、开发不灵活,若有新的业务需求只能往原有代码上加逻辑,这样对开发团队成员要求高,若团队成员更替频繁,新成员必须先熟悉团队的开发框架,很难适应这种开发模式、还有随着系统业务增多,功能增加,数据量越来越大,更是无法满足高并发下的业务需求;若我们采用微服务架构,那就将我们整个系统拆分为多个业务,将每个业务做成一个服务,服务之间采用HTTP(也可以使用消息队列RoocketMQ,Kafaka)通信,而且每个服务可以采用不同的开发语言、使用不同的存储方式,根据不同业务的并发需求,我们可以单独对某个服务做集群部署,增强系统的负载能力,由于每个服务都是独立部署的,每个服务的修改和部署对其他服务没有影响,当然,微服务也有一些缺点,比如:代码的重复,某些底层功能需要被多个服务所用,为了避免将“同步耦合引入到系统中”,有时需要向不同服务添加一些代码,这就会导致代码重复;开发人员需要考虑分布式系统的问题,如网络延迟、异步机制、系统容错性、分布式事务等;另外运维开销及成本也会增加,微服务架构可能需要运行数十个独立的服务,并可能需要支持多种语言和环境,对运维人员的要求也比较高。

小结:微服务架构有很多吸引人的地方,在拥抱微服务之前,我们要根据团队的实际情况以及项目实际情况选择是否适合采用该架构。

.NET Core是适用于 windows、linux 和 macos 操作系统的免费、开源托管的计算机软件框架,是微软开发的第一个官方版本,具有跨平台 (Windows、Mac OSX、Linux) 能力的应用程序开发框架 (Application Framework),未来也将会支持 FreeBSD 与 Alpine 平台,也是微软在一开始发展时就开源的软件平台 。

由于 .NET Core 的开发目标是跨平台的 .NET 平台,因此 .NET Core 会包含 .NET Framework 的类库,但与 .NET Framework 不同的是 .NET Core 采用包化 (Packages) 的管理方式,应用程序只需要获取需要的组件即可,与 .NET Framework 打包式安装的做法截然不同,同时各包亦有独立的版本线 (Version line),不再硬性要求应用程序跟随主线版本。

.NET Core的优势:

.NET Core 3.0现在支持了WPF和Windows Forms的开发,同时还支持UWP,WPF和Windows Forms三者间的混合开发,这为开发人员提供了灵活性,可以将UWP的现有接口引入Windows窗体和WPF中。

.NET Core 更适合跨平台的开发。 .NET Core 应用支持Windows,Linux和Mac OS。微软很受欢迎的代码编辑器 Visual Studio Code 支持Windows,Linux和Mac OS。VS Code还支持智能提示和调试,许多第三方代码编辑器(如Sublime、Emacs和VI)也都是使用.Net Core开发的。

.NET Core支持微服务架构,它允许跨平台服务与.NET Core一起使用,包括使用.NET Framework、Java、Ruby或其他语言开发的服务。

.NET Core的模块化,轻量级和灵活性,使在容器中部署.NET Core应用程序变得更加容易。而容器可以部署在任何平台包括云,Linux和Windows上,. Net Core在Docker和Azure Kubernetes Service上都运行良好。

.NET Core每个版本之间的兼容性很好。你可以在同一台电脑上面同时运行不同版本的应用。

 

原文地址:https://www.cnblogs.com/minghon/p/11741519.html

时间: 2024-10-02 19:11:55

浅谈微服务架构与.Net Core的相关文章

浅谈微服务架构与服务治理的Eureka和Dubbo

前言 本来计划周五+周末三天自驾游,谁知人算不如天算,周六恰逢台风来袭,湖州附近的景点全部关停,不得已只能周五玩完之后,于周六踩着台风的边缘逃回上海.周末过得如此艰难,这次就聊点务虚的话题,一是浅谈微服务的架构设计,二是聊聊微服务中广泛用于服务治理的Eureka与RPC框架Dubbo异同点. 一.微服务的架构设计 之所以想聊一下这个话题,主要有感于最近接触的两个新的微服务项目--两个项目的架构设计出自两个人之手,却不约而同的使用了相同的设计理念,项目结构非常类似.又想到就职于上家公司时接触到的项

浅谈微服务架构(四)——容错模式2

3. 限流模式 服务的容量和性能是有限的,在第3章中会介绍如何在架构设计过程中评估服务的最大性能和容量,然而,即使我们在设计阶段考虑到了性能压力的问题,并从设计和部署上解决了这些问题,但是业务量是随着时间的推移而增长的,突然上量对于一个飞速发展的平台来说是很常见的事情. 针对服务突然上量,我们必须有限流机制,限流机制一般会控制访问的并发量,例如每秒允许处理的并发用户数及查询量.请求量等. 有如下几种主流的方法实现限流. 1)计数器 通过原子变量计算单位时间内的访问次数,如果超出某个阈值,则拒绝后

浅谈微服务的来龙去脉

作者:王清培(Plen wang) 沪江 公共业务平台 应用架构师 转载至沪江技术学院微信公众号 背景介绍 最近一段时间公共业务平台在进行大面积的重构,对原来的技术栈进行迁移,逐渐往Java.Go.Node.js等开源.自由为主的技术体系中过度. 虽然这主要是替换技术框架,但也是我们应用系统进行重新设计.业务流程重新梳理的一个好机会,我们将利用这次机会来重构之前发现的一些问题. Martin Fowler大师<重构>一书中有说过一句话,大概意思就是,"每次对原有系统进行修改调整的时候

谈微服务架构(转)

时间 2016-03-22 11:38:33  人月神话的BLOG 原文  http://blog.sina.com.cn/s/blog_493a84550102w5x6.html 主题 微服务 其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是

Health Check in eShop -- 解析微软微服务架构Demo(五)

引言 What is the Health Check Health Check(健康状态检查)不仅是对自己应用程序内部检测各个项目之间的健康状态(各项目的运行情况.项目之间的连接情况等),还包括了应用程序对外部或者第三方依赖库的状态检测. Why use Health Check 现在我们的项目越来越多的从单体多层架构转换成多项目多层架构即现在流行的微服务架构. 原来我们的App把各个模块分层分项目处理,比如Users项目仅仅处理User的一些业务需求,但在整个项目使用的时候,我们仅仅需要引用

(1).NET CORE微服务 Micro-Service ---- 什么是微服务架构,.netCore微服务选型

开发工具:VS2017 .Net Core 2.1 什么是微服务?单体结构: 缺点:1)只能采用同一种技术,很难用不同的语言或者语言不同版本开发不同模块:2)系统耦合性强,一旦其中一个模块有问题,整个系统就瘫痪了:一旦升级其中一个模块,整个系统就停机了:3)要上线必须一起上线,互相等待,无法快速响应需求:4)集群只能是复制整个系统,即使只是其中一个模块压力大: 微服务:不同模块放到不同的进程/服务器上,模块之间通过网络通讯进行协作.适用于:模块比较多,访问量比较大的互联网类系统,并不是所有项目都

【.net core】电商平台升级之微服务架构应用实战(core-grpc)

一.前言 这篇文章本来是继续分享IdentityServer4 的相关文章,由于之前有博友问我关于微服务相关的问题,我就先跳过IdentityServer4的分享,进行微服务相关的技术学习和分享.微服务在我的分享目录里面是放到四月份开始系列文章分享的,这里就先穿越下,提前安排微服务应用的开篇文章 电商系统升级之微服务架构的应用. 本博客以及公众号坚持以架构的思维来分享技术,不仅仅是单纯的分享怎么使用的Demo. 二.场景 先来回顾下我上篇文章 Asp.Net Core 中IdentityServ

.NET Core 实践:微服务架构的优点

微服务现在已经是各种互联网应用首选的云架构组件,无论是 BAT 还是 滴滴.美团 ,微服务都是重要的一环. 相对于微服务,传统应用架构有以下缺点: 1. 业务代码混杂,团队成员职责边界不清,团队协作体验不佳,开发效率低下. 传统应用架构中,各个业务模块代码都存在于同一个应用当中,各个业务模块之间交互逻辑复杂,代码统统混在一起,难免出现要去别人代码里改代码的情况 2. 代码耦合度高,日趋臃肿,难以重构,维护成本越来越高. 感受过被F12支配的恐惧吗? 3. 容错能力弱,单点故障引发全局崩溃. 4.

多研究些架构,少谈些框架(1) -- 论微服务架构的核心概念(转)

微服务架构和SOA区别 微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为新的理念和原来的分布式系统,或者说SOA(面向服务架构)是什么区别呢?我们先看相同点: 需要Registry,实现动态的服务注册发现机制: 需要考虑分布式下面的事务一致性,CAP原则下,两段式提交不能保证性能,事务补偿机制需要考虑: 同步调用还是异步消息传递,如何保证消息可靠性?SOA由ESB来集成所有的消息: 都需要统一的Gateway