深圳专业网站设计公司,seo站外优化最主要的是什么,搜狗站长,免费推广网站有哪些平台如今框架两字已经烂大街了#xff0c;xx公司架构设计随处可见#xff0c;不过大多看个热闹#xff0c;这些框架如何来的#xff0c;细节又是如何思考的#xff0c;相互之间的隔离依据又是什么...相信很多朋友应该依然存在自己的疑惑#xff0c;特别是越来越火热的微服务以… 如今框架两字已经烂大街了xx公司架构设计随处可见不过大多看个热闹这些框架如何来的细节又是如何思考的相互之间的隔离依据又是什么...相信很多朋友应该依然存在自己的疑惑特别是越来越火热的微服务以及衍生的微服务网关产品正好最近打算写一个小开源框架OSS.Core过程中有一点思考通过这篇文章记录一下也希望能尽量帮助大家去理解一下大概围绕以下几个问题 1. 微服务产生的由来 2. 微服务的设计思路 3. OSS.Core框架的设计和实现 在展开讲述之前我希望大家首先要明白传统架构和微服务架构之间不是相互独立/对立关系微服务是在传统框架下为了应对并发维护等问题衍生出的逻辑概念更多的是在项目不同阶段的思考和解决问题方式的转变。其次把逻辑架构和物理架构(文件) 区分开来多数时候逻辑架构和物理架构对应的不过有时一个物理架构中是可以包含多个逻辑架构的。
一. 微服务产生的由来 微服务主要是将一些大型的复杂的应用拆解为多个服务组合每个服务自治以达到更加灵活维护方便的效果。 为了更好的理解我们先来看下常见三种解决并发的方式 1. 添加数据库主从分离甚至多主写入或者分区等机制在应用程序中对应修改连接串或添加访问中间件来提高数据库的处理能力。 2. 由于数据库资源相对紧张并且比较耗时为了提高访问速度这个时候一般也会通过分布式缓存等来减少对底层的访问。 3. 负载均衡分流处理在大量请求抵达应用程序之前将其分散到不同的机器上来解决单机带宽和性能瓶颈问题。 当然解决并发还有很多其他的方式如前端静态文件压缩CDN加速IP速率控制等这里先略过。 以上这三种方法很多朋友应该都见过之所以这里列一下再结合这张图可以更加容易的对比出传统整个服务到微服务之间的变化 在传统的整体服务框架中模块之间存在着很大的耦合项目内部存在互相调用以及各种复杂聚合操作所以在多数情况下只能整体部署在左侧图中我们可以看到负载均衡时我们需要整体部署在多台机器上相对数据库也是如此而一个项目中每个模块的需求是不一样的。 例如产品和下单模块的访问频率和流程的复杂度上有着很大的不同下单频率相对较小复杂度高我们更希望运行在预算能力高的相对少机器上也方便更快的排查问题和维护。右图中可以看到把服务细化之后我们可以用更小的部署单元来根据情况进行组合。 同时在互联网产品快速迭代的今天一个产品需要具有快速为不同终端上线不同应用功能的能力同时业务的调整能够快速的上线传统的整体服务模式已经力不从心。微服务因为已经化整为零反而因为各模块的独立能很快相互组合并且每个模块可以根据不同的需求点采用不同特性的编程语言。 二. 微服务的设计思路 因为每个产品都有自己的标准和重点所以设计服务单元时也各有不同但是有最基本一点 服务自治 当你设计一个微服务模块时需要保证当前服务的独立特别是数据模块的独立其他服务无权直接操作当前服务下的数据库模块对外交互只能通过服务接口来完成。因为模块的独立所以你可以选择适合的编程语言以及对应的部署规模。达到局部的灵活优化。微服务相互独立带来以上便利的同时它也带来了一些我们需要面对的问题 首先如何如何界定当前服务的边界如何确定当前服务治理范围。 既然是要最小化服务单元那就要确定服务的职责边界问题这个问题建议结合服务生命周期流程领域以及预估规模 这几点综合考虑例如用户服务在访问量小人员少时可以把用户基础信息余额账户放在一个服务模块下以减少工作量减少精力分散。规模大时再分基础服务和资产服务。 其次跨服务数据查询问题 例如在客户端中搜索商品还可以搜索用户或者统计数据查询等如何处理。对于这种我给两个处理方式 1. API Gateway 这种情况适合在服务单元过多客户端需要查询使用不同的服务单元中的数据这个时候我们可以针对性的搭建一个API服务网关请注意和APP Gateway区分开通过这个网关聚合多个服务客户端只需要和当前网关交互网关聚合转发给不同的微服务。如下图 2. 数据冗余或者后台数据同步 比如在订单信息中我需要用户的名称等少量用户字段这个时候完全可以把这几个字段冗余到订单微服务数据模块下。又比如在统计模块下其数据制造者和查询者完全属于不同的对象无很高实时性那我建议创建一个统计服务以及对应的统计数据库其他服务通过事件消息交互更新对应的统计数据查询时通过统计服务自己的数据即可完成。 再次如何解决服务间的通信问题 因为我们已经将服务之间相互独立断绝直接操作不同服务数据库的可能。那么数据的一致性如何处理在传统的服务模型中因为都糅合在一块我们可以通过事务或者存储过程来保证数据的一致性。常见的有以下两个方式 1. 异步事件消息驱动 这类解决方案适合对数据实时性要求相对不高的场景比如上边的统计服务更新在下单等服务的事件触发后给消息队列推送响应的消息通知订阅此队列的服务接收更新数据。如图 2. 直接接口请求HTTP,RPC 一般情况下不建议以防止产生级联依赖。这类主要针对数据实时性要求较高的请求比如在秒杀下单过程中需要立即知道库存服务扣除是否成功等。注.net 下对task的支持已经特别好了http请求建议使用异步同时前端返回TaskActionResult,减少因IO操作造成的工作线程消耗 最后客户端如何访问 当我们封装完服务之后这个服务如何和最后的客户端如何访问这个需要根据实际的安全规则和要求各自决定了一般情况下如果服务相对较少功能不算复杂的情况下可以直接暴露服务接口给客户端进行访问如图 或者通过上边说的 API Gateway 的形式提供给客户端当然也有很多已经成熟的微服务网关比如Azure云上的Service Fabric或者API Management都是可以的。 三. OSS.Core框架的思路和实现 OSS.Core这个项目是我最近在写的一个小开源产品了解的朋友应该知道我在前面写了一些组件像: OSS.SocialOSS.PayCenterOSS.CommonOSS.Http 这个项目希望能把这几个组件给串联起来上边已经介绍了微服务的大概思考方式我将会在这个产品的逻辑架构中尽可能的体现这一点先把项目的物理架构图展示一下 这个项目中AdminSiteWebSite 放置在FrontEnds文件夹下两个问站点分别是用户前端和后台管理前端 WebApiServiceDomainMos图中的Models和Interface类库在 Layers 文件夹下构成API基础 Infrastructure业务相关通用实体枚举辅助类 和 Common业务无关相关实体辅助类 作为基础设施类库可以在各级类库中调用 Repositories暂时是项目中的OSS.Core.RepDapper的Mysql实现以后可能增加其他数据库支持主要是Rep.. Interface的具体实现。 Plugs是实现了Common插件下的日志缓存和配置接口具体实现可以通过Common在各级直接调用。 回到微服务的话题上在这个产品中我不会为每个服务创建一套Layers下的类库实现我将在这个项目通过文件夹隔离的形式来分开各个服务你可以把WebApi当做一个API Gateway内部的调用顺序我希望是这样的 现在代码结构图 原文地址http://www.cnblogs.com/osscoder/p/6892088.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
