外贸网站建设 公司,wordpress 数字不连续,网站建设流程包括哪些环节,建设俄语2p2网站前言
前几天在博客园看到有园友在分享关于微软的一个微服务架构的示例程序#xff0c;想必大家都已经知道了#xff0c;那就是eShopOnContainers。
我们先不看项目的后缀名称 OnXXX #xff0c;因为除了 OnContainers 还有 OnAzure#xff0c;OnWeb#xff0c;OnKuberne…前言
前几天在博客园看到有园友在分享关于微软的一个微服务架构的示例程序想必大家都已经知道了那就是eShopOnContainers。
我们先不看项目的后缀名称 OnXXX 因为除了 OnContainers 还有 OnAzureOnWebOnKubernetes 以及 OnServiceFabric。
我们就还是来先说说 eShop 这个项目吧eShop 是 ASP.NET Core 发布之后微软新开源出来的一个示例项目想必大家之前也都知道微软放出来的关于 Web 的示例项目还有 PetShop, Music Store 这两个项目。关于这两个项目我们就不做过多的介绍了但是关于这两个项目的架构风格我们不得不提起。
PetShopWebFrom 的示例程序。典型的三层架构风格的应用程序。
MusicStore: 针对于 MVC3-5 框架和 EF 的一个示例程序。无明显架构风格。
eShop: 针对于 ASP.NET Core 的示例程序。它是一个 Rest 架构风格的应用程序。
我们从微软放出来的这些示例程序中也许可以看出些许东西那就是近些年来关于架构风格的演变或者叫微软架构风格的演变在这里我不打算讨论关于软件架构更加深层次的一些这种东西我们只从我们能够理解的东西看起。
微软架构风格
我不知道有没有人看过这本书目前已经绝版了它是早年间关于微软架构风格的一本指南书里面描述了微软体系的架构风格的一些汇总。 这本书中列出来了以下这些架构风格
Client/Server Architectural StyleComponent-Based Architectural StyleDomain Driven Design Architectural StyleLayered Architectural StyleMessage-bus Architectural StyleN-Tier / 3-Tier Architectural StyleObject-Oriented Architectural StyleService-Oriented Architectural Style
我们可以看到微软所开源出来的这些示例程序其实都是在遵循这些架构风格中的某一种或者是多种。 PetShop 属于 N-Trie Music Store 属于 LayeredeShop 属于 Service-Oriented。当然在 eShop 中微软不但使用了 Service-Oriented 其中还包括 Domain Driver Design(DDD), Message-bus 也都应用到了示例程序中。
由此我们可以看出在现代的应用程序架构风格中已经不是某一种架构风格可以独自独领风骚了它一定是多种架构风格的混合体互相补充来构建更加强大的应用程序解决方案。
下面进入到我们本篇博客的主题微服务。不应该是 ASP.NET Core 中的微服务有同学可能会说了微服务是一种架构风格它并不和某一种语言相关也不是只有.NET 中才有微服务。在这里我想说的是我不想去讨论大众眼中的微服务因为太多人去说这些东西了不就你打开 InfoQ 或者 cnBeta 这些网站满屏的都是微服务的东西。 所以你可以说我的微服务叫 Savorboard 式微服务。
既然要说 ASP.NET Core 中的微服务那就必须又要说到 eShop 这个项目了之前没有给大家分享关于 eShop 这个项目的一些信息其实是有原因的因为这个项目有很多东西它没有实现完或者是叫它还是一个半成品给大家分享的话大家又运行不起来所以就一直在等一个合适的时间来做。
ASP.NET Core 微服务
ASP.NET Core 其实是一个非常适合做微服务的一个 Web 框架它足够的轻量级并且拥有超高的性能。并且对于 Rest 这些风格的接口支持的非常的友好。更多好处我其实不太愿意去说因为只有你自己去体会才会知道。还不如来点实在的去教你们怎么在 ASP.NET Core 中构建一个或者叫一组微服务集群。在我看来有时候讲那么多理论也都是扯淡的。那就废话不多说开始吧。
在开始之前还是要说一句你的架构一定要符合你的业务和需求不要为了架构而架构。举个例子你的网站每天的访问量就那么几百号人以后也不会大量的增加你又是分布式又是大数据又是docker集群的这不没事给自己找事干么。切记。
第一步业务拆分。
业务拆分其实有时候是需要经验积累的有时候不仅仅是需要你有软件架构经验还需要你有行业知识的经验。这时候你的业务拆分的才足够合理不会随着时间的推移导致你的微服务变“大”。
如果你对 DDD 中领域建模这种软件建模方式在行的话可能会帮助你解决大量的潜在问题如果你不会也没关系因为你可以去学呀~ 2333
第二步建模。
在微服务架构中建模仍然是重要的一步因为你使用的是 EF Code First , 建模质量的好坏肯定是和你以后的代码质量挂钩了。如果你不使用 EF那我们就不能愉快的做朋友了。
给大家个小提示如果你的项目中全是增删改查没有什么业务算法或者逻辑可言的话就让你的模型尽量的符合你的界面上的显示字段这样可以最大化的提升开发效率。
第三步写代码。
这个时候我希望你抛弃掉三层架构这种架构风格的设计不是说那种不好而是有更加便捷的方式了你需要知道你写的每一个 Action 都应该是尽量的简单再去调用 BLL 层绕一大圈子就为了一个增删改查纯粹是给自己找活干那样并没有提高项目的可维护度。
前段时间在 QQ 群听学姐说过这么一句话就是佛家的人生三重境界之说, 即“看山是山, 看水是水; 看山不是山, 看水不是水; 看山还是山, 看水还是水。”
这一句话对于软件架构的设计过程中同样适用在最初的时候我们对于软件程序不懂就按照官方给的示例程序来进行设计即看山是山随着我们的知识见解经验的积累我们有了自己的一些看法理解出了自己的各种框架即看山不是山随着时间的推移我们已经悟到了其中的精髓又回到了官方示例大道至简即看山还是山。
第四步重构。
当你写完代码之后我认为有一个比较重要的步骤就是对写的代码进行一番重构重构一般从两方面下手第一方面是代码的命名以及格式第二方面是代码的组织结构。
针对于代码命名以及格式的重构其实是有方法和技巧的比如方法的命名以及方法的拆分等可以从重构这些书中来获取一些指导意见等对于代码格式的话基本上现代的IDE都提供了很好的格式化工具使用便是。
针对于组织结构的重构有时候是需要依赖很多你的经验的经验丰富的程序员知道如果的去对写过的代码进行抽象然后利用某种设计模式或者是面向对象的原则来让代码更加的利于维护和扩展这种技能往往更难掌握需要你去阅读很多的别人优秀的代码然后去思考和学习。
OK以上就是在构建单个微服务程序的个人总结的一些指导原则吧。
部署方式
指导原则可以帮助我们在构建系统的时候使其保持一个良好的结构但是你还需要从整体上来把控整个微服务的布局。什么意思呢
我们知道微服务最良好的部署方式就是使用 Docker 容器进行部署因为这样便于管理和配置。在以前的单体结构的项目中也可以使用Docker进行整块的部署我们可能部署到多个容器中然后前置一个负载均衡器进行路由的转发这样也是可以的。
通常情况下即使我们的程序架构风格不是微服务那么在组织代码结构时也会进行模块的划分比如划分为会员商品库存等。下面是一个单体应用整块部署使用Docker的部署图 但是这种模式其实与容器的初衷是有一点违背的容器所倡导的是一个容器只做一件事情。整块部署有一个明显的缺点是如果随着应用程序的扩展那么每次代码的修改都要全部进行重新发布但是我们经常修改的代码可能就是某一快的功能而另外一些代码则永远不会动这样不但发布程序的时候发布包很大也容易出错出问题造成的影响也比较广。
比如在一个电商网站中有一些模块是经常发生变化的比如一些促销产品等页面这些页面的访问量也很大而另外一些页面比如用户中心积分查看历史订单查看这些功能则不会经常变动并且访问量要小很多。那么如果他们都在一个系统中势必会引起这些问题1、性能优化如果访问量很高的模块出现性能问题那么你只能针对整个程序进行扩展部署而不是单个模块。2、测试由于模块的依赖那么在修改一块地方的时候必须重新对整个应用程序进行一次测试并且重新部署所有这些实例。3、无法进行扩展你无法简单的进行接口或者服务的扩展这会使SOA变得很困难。
那么我们就再顺便说一下SOA我们知道大多数的公司在 .NET FX 时代使用 WCF 技术进行项目的 SOA 化比如常见简单的会使用 SOAP ,HTTPMQ等进行通讯他们也会把系统进行划分子系统和分层。听起来可能和微服务有点像那么他们有什么区别呢 想必这是一个很多人讨论过的话题那么直接说结论吧。 微服务它来自于SOA但是和SOA不同的是它并没有那么重量级什么意思呢比如它没有SOA中的像集群的Broker, 那么大的组织的划分中央负责人, 还有企业服务总线 (ESB)等。
然后就是我们的主题微服务微服务架构的定义就是一组小型的服务。每一个服务都位于自己的进程中并且使用诸如HTTP, WebSockets或者 AMQP 之类的协议进行通讯。它很小并且专注于做好一件事这个很重要它看起来像OOP中的单一职责原则如果你2周之内不能完成一个微服务模块那么可能你对于边界划分出了点问题。
关于微服务的优缺点不做过多的介绍了有兴趣的同学可以看一下在我博客里面的 Martin Fowler 的 这篇文章。
这篇文章提到了『微服务设计』这本书如果你想对微服务有更多了解的话可以看一下这本书建议购买。 微服务中的一些技术挑战
下面需要说的是个人对于在构建微服务的过程中会面临的一些问题或者说叫做挑战吧。
1、微服务的边界怎么定义。
上一篇文章已经提到过了在定义微服务边界的过程中DDD中的指导原则会帮助你大忙。 这可能是你在构建微服务过程中遇到的第一个难题一个良好的微服务能够对其他微服务尽可能少的依赖同一个应用程序中你需要用不同的上下文进行解耦每个上下文有可能是使用不同的程序语言的。这些上下文应该被独立的定义和管理。比如一个User在 Identity 上下文可能是一个用户在 CRM 中是一个客户在订单上下文是一个买家等等。
2、如何跨微服务进行查询。
因为我们已经微服务化了所以我们的应用程序数据可能分布在不同的数据库中那么如何实现从多个为微服务器数据库中查询数据成为一个难题了。
比如我们前台的数据展示页面需要一个销售统计的报表其中的数据分别来源于订单库存和商品。那么我们应该怎么样来处理这种复杂性呢 目前流行的解决方案有以下几种
API网关。 使用API网关来对多个微服务器的数据库进行聚合。 但是在实现这种模式的时候你需要非常的小心它有可能是你系统中性能的瓶颈甚至它有可能违背微服务的自治原则。为了尽可能避免这个陷阱你需要设计多个细粒度的 API 网关每个网关关注系统一个垂直领域的“切片”区域或者是一个业务领域。现在大部分的云提供商都提供的有 API 网关相关服务比如AWS的 Amazon API GatewayAzure 的 Establish API Gateways 等借助于这些服务可以方便的对 API 进行管理。
CQRS与读表。 不知道大家有没有听说话物化视图Materialized View这个名词。你可以理解为远程视图使用这种方法你可以提前准备好一个只读表其中包括多个微服务的数据这个只读表的结构和你展示给客户的页面数据是对应的。
那么有同学可能会存在这样一个问题假如我基于不同的数据库建立一个物化视图那么在我建立物化视图的过程中我应该怎么样进行查询因为对于单个数据库的查询可能仍然是复杂的。确实如此在以前单个应用程序的时候我们在呈现个客户端需要的数据的时候可能会是一个复杂的SQL Join连接查询的结果。那么这里的解决方案就是我们需要建立一个和我们业务无关的一个单独的数据库然后这个数据库中会包含一些和界面上需要的数据进行一一对应的一些查询用的表然后我们应用程序中引入 CRQS 这种模式将需要的数据写入到这些查询表中。
这不仅解决了跨微服务查询这个难题并且也提高了性能。但是引入CQRS也就意味着你需要拥抱最终一致性。
数据中心的 “冷数据”。 对于一些不需要做实时数据的复杂查询或者报表通常是将微服务的“热数据”作为“冷数据”导出到数据中心以供报表。这个数据中心可能是一个基于大数据的系统比如 HadoopAWS的RedshitAzure的SQL Data warehosue等。
同步的过程你可以使用事件驱动这种通讯技术或者是一些数据库提供的基础设施中的导入/导出工具等。如果使用事件驱动的话其过程有点类似上面的CRQS查询过程。
3、如何实现多个微服务的数据一致性。
我们知道在每个微服务都是具有高内聚的特点的外部想访问微服务的数据只能通过API访问那么我们在实现一个微服务到另外一个微服务这种业务流程的时候怎么同时保持多个微服务之间的一致性呢
我们回到 eShop 这个微软的示例项目上来来看看怎么处理的。 首先Catelog 这个微服务是负责维护商品相关的信息包括库存。 Ordering 这个微服务负责订单的管理当新创建一个订单的时候它必须验证这个订单的商品是否具有足够的库存如果不够可能涉及到缺货登记所以它就必须要和Catelog微服务打交道。在以前单服务的程序中可以简单的使用ACID事务来进行检查并且直接更新可用库存。但是现在不能这样了每个微服务都拥有自己的数据库当前的服务不能直接去操作其他服务的数据库的这个时候我们为了实现我们需要的功能怎么办呢我们可以使用异步通讯比如消息或者事件驱动这种方式这也是 eShop使用的方式。
这里就涉及到一个理论知识就是 CAP定理。也就是说你必须要在可用性和ACID强一致性之间做出选择。大多数基于微服务的场景都需要可用性和高可扩展而不是强一致性。所以为了保证在关键场景下应用程序能够正常响应我们一般会选择牺牲强一致行从而追求最终一致性。
4、如何跨微服务进行通讯。
微服务之间的通讯是一个比较大的技术挑战。这个时候你不应该去关注你应该使用什么协议比如是使用 Http、Rest、AMQP、消息、或者其他东西。相反你应该了解每种协议的优缺点你使用该协议想达到什么样的一个目的以及这种协议怎么样和你的微服务更好的进行耦合。根据耦合程度当发生故障的时候是不是对系统有非常大的影响。
像微服务这种分布式系统中是由许多的组件在很多的服务器之间共享的。这些组件最终可能会发生故障当这些组件故障的时候你需要考虑的是是否会引起更大的故障所以你需要在设计你的微服务的时候充分考虑到这些通讯过程中常见的风险。
目前一种比较流行的做法是使用基于 HTTP 协议 REST 方式的微服务这是因为它们很简单。而且基于 HTTP 的这种方式是完全可以接受的当然这也取决于你当前的使用场景。 假如说你是在客户端或者是API网关中使用 HTTP 进行请求和相应以及进行微服务交互那么它足够用了。但是假如你是跨微服务之间进行HTTP的调用长链的话就像在使用数据库事务那样使用那么你的应用程序最终会遇到麻烦的问题。
事实上如果你在内部微服务之间通讯也是通过HTTP的方式那么我可以理解为你正在使用的是一个单机的应用程序只是他们是基于进程之间的HTTP而不是进程内的通讯。
因此我们在设计微服务的时候为了其具有更好的弹性我们应该尽量减少这种跨微服务的通讯。这种情况下我们可以使基于消息或者事件的异步通讯方式来达到目的。
那么在 .net 中有没有什么现成的解决方案可以用呢 答案是肯定的请向下看。
总结
这一篇主要是对上一篇的一个补充以及涵盖了微服务的部署方式以及在构建服务器的过程中会遇到的一些技术挑战。
下一节我们将说一下 基于消息的异步通讯 我将会给出在 .NET Core 中的具体的解决方案敬请期待。 相关文章
开篇有益-解析微软微服务架构eShopOnContainers一Identity Service - 解析微软微服务架构eShopOnContainers二Catalog Service - 解析微软微服务架构eShopOnContainers三EventBus In eShop -- 解析微软微服务架构eShopOnContainers四微服务的概念——《微服务设计》读书笔记微服务架构师的职责——《微服务设计读书笔记》建模:确定服务的边界——《微服务设计》读书笔记微服务集成——《微服务设计》读书笔记服务的协作服务间的消息传递——《微服务设计》读书笔记拆分:分解单块系统——《微服务设计》读书笔记部署:持续集成CI与持续交付CD——《微服务设计》读书笔记测试——《微服务设计》读书笔记监控——《微服务设计》读书笔记安全——《微服务设计》读书笔记康威定律和系统设计——《微服务设计》读书笔记规模化微服务——《微服务设计》读书笔记Net分布式系统之微服务架构
原文地址http://www.cnblogs.com/savorboard/p/aspnetcore-microservice2.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
