一、背景&问题

  之前框架是一个基于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、一致性:采用数据最终一致性策略。

四、框架总体设计

    
.Net微服务架构_第1张图片
图1- 系统架构示意图

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

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

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

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

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

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

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

  

五、软件架构设计

  ![](https://s1.51cto.com/images/blog/201809/16/c14c421330ee943366926a7f34eb9129.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

                                                   图2- 软件架构示意图

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

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

六、结语

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

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

作者:刘蔡涛
公众号:【51dotnet】![](https://s1.51cto.com/images/blog/201809/16/aa9fb314934cde606d0f472e0b6c88da.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)