Net分布式系统之五:微服务架构

  因工作较忙,抽时间将框架遇到的问题和框架升级设计进行记录。

一、背景&问题

  之前框架是一个基于SOA思想设计的分布式框架。各应用通过服务方式提供使用,服务之间通信是RPC方式调用,具体实现基于.NET的WCF通信平台。框架存在如下2个问题:

  1、高并发处理能力不足。一当高并发请求,可能出现多个服务待定处理,导致整个系统出现瓶颈。

  2、随着移动端广泛应用,服务不能灵活支持APP应用。

  3、系统持续集成部署过于繁琐,遇到问题不好定位。

  基于以上存在问题升级框架,结合当前主流的架构思想,将系统进行服务化思维,就是“微服务架构”。



二、微服务架构

  微服务架构(Microservices Architecture)是将系统拆分为多个服务,俗称为应用服务。应用服务实现单一、具体的业务应用功能,支持独立部署维护,多个应用服务构建成系统。应用服务之间通过轻量级通信框架进行,并且支持应用服务用不同技术或者平台实现。微服务架构是SOA架构设计思想另一种实现方式。微服务架构有如下特点:

 1、微服务架构好处

  (1)横向扩展应用服务提升系统并发处理能力

  (2)应用服务独立部署维护,有利于迭代开发升级持续部署

  (3)架构灵活支持多种技术实现

  (4)有利于应用服务实现高可用性

 2、微服务架构不足

  (1)对系统设计有一定要求,尤其是拆分技术应用服务接口

  (2)导致系统实现复杂度的提高

  (3)需要确保系统数据一致性机制

  (4)导致系统维护要求和成本提高

  系统是否需要采用微服务架构进行构建是由项目需求决定。采用微服务架构进行设计构建系统,对团队成员能力比传统要求高,尤其是设计能力。



三、框架设计原则

  1、可扩展:支持不修改系统功能,按需扩展服务器资源。

  2、高可用:支持分布式部署双机热备机制,满足系统高可用性的要求。

  3、高并发:支持快捷扩张应用服务处理能力,提升系统处理能力,满足并发请求。

  4、安全性:访问安全通过统一认证访问;信息安全通过加解密、签名传输;网络安全通过网络隔离及防火墙;数据安全通过定时备份及高容错能力。

  5、一致性:采用数据最终一致性策略。



四、框架总体设计

    

图1- 系统架构示意图

  如图所示,系统架构基于SOA架构设计思想,并且采用微服务架构方式进行设计和构建。将系统呈现和数据进行分离。系统呈现基于网页进行实现,支持多种前端UI框架整合及自定义开发;数据由应用服务提供,统一通过“网关API”提供使用。架构支持通过网络层、应用层的负载均衡中间件等,实现高可用和并发处理能力。架构将一些基础公共功能抽离构建成中间件。

  1、网关API:应用服务通过网关API统一对外提供服务。网关API基于http协议、以restful方式提供统一服务接口,约定接口通信协议,支持系统呈现的功能,以轻量级的通信方式,满足不同客户端。网关API实现统一数据访问权限控制、路由应用服务、限流等功能。

  2、消息平台:负责应用服务之间更新同步信息,将原有系统架构分布式事务调用更新信息的方式,调整为通过消息异步发布/订阅处理,保证数据最终一致性,应用服务之间降低耦合度和强依赖关系。高并发能力下,取得缓存作用。

  3、服务注册监控中心:负责应用服务注册发布登记,同时监控应用服务接口运行情况,支持动态控制应用服务接收请求,实现“去中心化”服务控制。组件实现服务注册登记、监控等功能。

  4、认证中心:负责架构访问统一身份认证。通过用户口令和权限进行控制访问。结合“网关API”实现安全访问、限流等功能,同时实现页面管理功能。

  5、日志管理系统:负责记录系统日志,提供服务接口和组件,业务代码通过异步方式将日志信息传输到“消息平台”,日志管理系统订阅“消息平台”的日志信息进行处理存储。同时提供日志管理功能

  6、缓存中心:基于Redis分布式内存数据库,搭建架构统一缓存中心,提供统一缓存服务。

  

五、软件架构设计

  

图2- 软件架构示意图

  如图所示,系统架构以微服务架构方式进行开发,从切面观察每个应用服务进行垂直独立开发,根据职责划分层次,从上而下分为四个层次,分别为Web层、服务接口层、业务逻辑层及数据访问层。Web层主要负责系统功能呈现表达,直接面对用户;服务接口层主要负责提供标准化服务接口,与呈现层对接;业务逻辑层主要实现应用业务逻辑,是应用服务核心部分;数据访问层负责数据持久化,支持业务逻辑层。各层次之间通过接口进行隔离,有利于后续维护扩展,减低依赖和影响。

  应用服务完成开发后进行集成部署。Web层将根据约定集成到Web应用容器,其余层次构建为应用服务进行部署,并将服务接口进行注册登记发布使用。

六、结语

  基础架构大致设计就这样,还需要考虑实施部署,可以考虑云平台弹性资源,再结合docker容器技术。

  后续再逐步介绍相关基础组件设计及实现原理。技术框架重于解决问题,设计依赖需求,需求来源实际业务场景。

作者:刘蔡涛
出处:http://www.cnblogs.com/Andon_liu

关于作者:专注于微软平台项目架构、管理。熟悉设计模式、领域驱动、架构设计、敏捷开发和项目管理。现主要从事ASP.NET MVC、WCF/Web API、SOA、MSSQL、redis方面的项目开发、架构、管理工作。
如有问题或建议,请一起学习讨论!

本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接。

如有问题,可以邮件:[email protected] 联系我,谢谢。

时间: 2025-01-02 13:35:08

Net分布式系统之五:微服务架构的相关文章

分布式系统(微服务架构)的一致性和幂等性问题相关概念解析

目录 前言 1. 分布式系统的数据一致性 1.1 分布式存储系统中的一致性问题 1.2 微服务应用的分布式一致性问题 1.3 对于一致性的正确理解 2.分布式一致性模型 3. 追求强一致性的约束--CAP定理 3.1 如何理解CAP三要素不可兼得 3.2 如何正确理解CAP定理 4. 一致性的妥协--最终一致性和Base原则 4.1 CAP,BASE以及ACID的关系 5. 分布式系统的幂等性 6.微服务架构的分布式一致性和幂等性问题 6.1 微服务架构下的分布式一致性问题 6.2 微服务架构下

微服务架构(Microservice Architecture)

之前一段时间,有听部门架构说起接下来公司要使用微服务架构来研发系统,当时没怎么在意,因为是第一次听说微服务这个名词(果然无知者无畏啊):正好赶上五一假, 我自告奋勇的,接了编写微服务架构培训文档这个任务(也许因为我是文科生,文笔稍微好点).五一假期三天,基本都是在看资料,梳理思路以及编写接下来的培训文档中度过. 下面,就说说我这几天的一些收获吧:先说说资料来源吧:有架构给我的一些资料,以及自己百度和论坛.社区找来的一些资料,权当做一个总结式的简介... 目录如下: 一.微服务架构介绍 二.出现和

微服务架构——不是免费的午餐

当我開始了解<微服务架构>的时候,我发现里面的中文文章是相当的少,于是開始试着翻译一些文章,比方这一篇<微服务--不是免费的午餐>.这篇文章是在某次讨论结束后听到的,和之前相似的是这样的差别有点相似于之前说的微内核与宏内核的差别. 译文例如以下: 文章是由Contino公司的CTO,Benjamin Wootton写的.Contino是一家在伦敦的咨询公司,专注于DevOps和持续支付. Microservices are a style of software architect

微服务架构设计

微服务 软件架构是一个包含各种组织的系统组织,这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系.系统架构的目标是解决利益相关者的关注点. Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizati

NET实现的DDD、CQRS与微服务架构

WeText项目:一个基于.NET实现的DDD.CQRS与微服务架构的演示案例 最近出于工作需要,了解了一下微服务架构(Microservice Architecture,MSA).我经过两周业余时间的努力,凭着自己对微服务架构的理解,从无到有,基于.NET打造了一个演示微服务架构的应用程序案例,并结合领域驱动设计(DDD)以及命令查询职责分离(CQRS)体系结构模式,对事件驱动的微服务系统架构进行了一些实战性的探索.现将自己的思考和收获整理成文,分享给大家. 微服务架构 在介绍源代码之前,我还

微服务架构的分布式事务场景及解决方案分析

分布式系统架构中,分布式事务问题是一个绕不过去的挑战.而微服务架构的流行,让分布式事问题日益突出! 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析! 如上图所示,假设三大参与平台(电商平台.支付平台.银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析: 1.电商平台中创建订单:预留库存.预扣减积分.锁定优惠券,此时电商平台内各服务间会有分布式事务问题,因为此时已经要跨多个内部服务修改数据: 2.支付平台中创建支付订单(选银行卡支付):查

微服务架构(Microservices)

说在前面 好久没写博文了,心里痒痒(也许是换工作后,有点时间了吧).最近好像谈论微服务的人比较多,也开始学习一下,但是都有E文,看起来半懂不懂的. Martinfowler的<微服务>,也算是入门必读了.有人翻译过,但是只有一半.还是自己练练手吧. 微服务 "微服务架构"一词在过去几年里广泛的传播,它用于描述一种独立部署的软件应用设计方式.这种架构方式并没有非常准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上,却有着显著特征. "微服务

细说微服务架构的优势与不足那点事

摘要: 一个微服务一般完成某个特定的功能,比如下单管理.客户管理等等.每一个微服务都是微型六角形应用,都有自己的业务逻辑和适配器.一些微服务还 会发布API给其它微服务和应用客户端使用.其它微服务完成一个Web UI,运行时,每一个实例可能是一个云VM或者是Docker容器. 微服务正在博客.社交媒体讨论组和会议演讲中获得越来越多的关注,在Gartner的2014 Hype Cycle上它的排名非常靠前.同时,软件社区中也有不少持怀疑论者,认为微服务不是什么新东西.Naysayers认为这就是S

微服务架构介绍

jhipser微服务架构介绍 内容提要 本文涉及以下内容: 微服务架构介绍 spring cloud介绍 jhipster架构介绍 微服务架构介绍 微服务概念 微服务和SOA很相似,都是按照业务功能把系统拆分成一个一个的服务.比如电子商务系统拆分成订单服务,商品服务等,每个微服务都是自治的,可以单独部署.微服务和SOA的区别是:微服务粒度更细,通信协议倾向于使用restfull api 而不使用webservice.微服务有很多优点,包括松散耦合.自治服务.分散化治理以及易于持续交付等等.微服务