微服务框架下的思维变化-OSS.Core基础思路

　　如今框架两字已经烂大街了，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请求建议使用异步，同时前端返回Task<ActionResult>,减少因IO操作造成的工作线程消耗）

　　最后：客户端如何访问

　　当我们封装完服务之后，这个服务如何和最后的客户端如何访问，这个需要根据实际的安全规则和要求各自决定了，一般情况下，如果服务相对较少，功能不算复杂的情况下可以直接暴露服务接口给客户端进行访问，如图：

　　或者通过上边说的 API Gateway 的形式提供给客户端，当然也有很多已经成熟的微服务网关比如Azure云上的Service Fabric或者API Management，都是可以的。

三. OSS.Core框架的思路和实现

　　OSS.Core这个项目是我最近在写的一个小开源产品，了解的朋友应该知道我在前面写了一些组件像: OSS.Social，OSS.PayCenter，OSS.Common，OSS.Http 这个项目希望能把这几个组件给串联起来，上边已经介绍了微服务的大概思考方式，我将会在这个产品的逻辑架构中尽可能的体现这一点，先把项目的物理架构图展示一下：

　　这个项目中AdminSite，WebSite 放置在FrontEnds文件夹下，两个问站点分别是用户前端，和后台管理前端

　　WebApi，Service，DomainMos（图中的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跨平台或扫描二维码关注

微服务框架下的思维变化-OSS.Core基础思路相关推荐

go-zero：微服务框架
go-zero 是一个集成了各种工程实践的 Web 和 rpc 框架,它的弹性设计保障了大并发服务端的稳定性,并且已经经过了充分的实战检验. go-zero 在设计时遵循了 "工具大于约定和 ...
go-zero：开箱即用的微服务框架
go-zero 是一个集成了各种工程实践的 Web 和 rpc 框架,它的弹性设计保障了大并发服务端的稳定性,并且已经经过了充分的实战检验. go-zero 在设计时遵循了 "工具大于约定和 ...
微服务架构下的熔断框架：hystrix-go
伴随着微服务架构被宣传得如火如茶,一些概念也被推到了我们的面前.一提到微服务,就离不开这几个字:高内聚低耦合:微服务的架构设计最终目的也就是实现这几个字.在微服务架构中,微服务就是完成一个单一的业务功 ...
java 微服务框架对比_多云架构下，JAVA微服务技术选型实例解析
[摘要] 本文介绍了基于开源自建和适配云厂商开发框架两种构建多云架构的思路,以及这些思路的优缺点. 微服务生态微服务生态本质上是一种微服务架构模式的实现,包括微服务开发SDK,以及微服务基础设施. ...
微服务框架-Spring Cloud简介（一）
Spring Cloud是一个微服务框架,相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案. Spring Cloud对微服务基础框架Netflix的多个开源组件进 ...
架构 | 微服务架构下如何解耦，对于已经紧耦合下如何重构？
点击上方"朱小厮的博客",选择"设为星标" 当当满200减40优惠码「J2KNAE」来源:知乎今天准备谈下微服务架构下各个微服务间如何解耦,以及对于已经紧耦 ...
微服务松耦合_超值干货：微服务架构下如何解耦，对于已经紧耦合下如何重构？...
今天准备谈下微服务架构下各个微服务间如何解耦,以及对于已经紧耦合的微服务如何进行重构.要明白实际上微服务后续出现的诸多问题往往都是一开始微服务模块划分就不合理导致,对于具体的模块划分方法和原则,我总结 ...
Java 微服务框架选型（Dubbo 和 Spring Cloud？），大厂 HR 如何面试
写在最前面,我总结出了很多互联网公司的面试题及答案,并整理成了文档,以及各种学习的进阶学习资料,免费分享给大家.扫码加微信好友进[程序员面试学习交流群],免费领取.也欢迎各位一起在群里探讨技术. 微服 ...
java微服务项目简历_微服务框架-SpringCloud简介
前面一篇文章谈到微服务基础框架,而Netflix的多个开源组件一起正好可以提供完整的分布式微服务基础架构环境,而对于Spring Cloud正是对Netflix的多个开源组件进一步的封装而成,同时又实 ...

微服务框架下的思维变化-OSS.Core基础思路

微服务框架下的思维变化-OSS.Core基础思路相关推荐

最新文章

热门文章