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

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

 

1、背景&问题

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

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

　　二、随着移动端普遍应用，服务不能灵活支持APP应用。

　　三、系统持续集成部署过于繁琐，遇到问题很差定位。

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

---

  

2、微服务架构

　　微服务架构（Microservices Architecture）是将系统拆分为多个服务，俗称为应用服务。应用服务实现单1、具体的业务应用功能，支持独立部署维护，多个应用服务构建成系统。应用服务之间经过轻量级通讯框架进行，而且支持应用服务用不一样技术或者平台实现。微服务架构是SOA架构设计思想另外一种实现方式。微服务架构有以下特色：

　一、微服务架构好处

　　（1）横向扩展应用服务提高系统并发处理能力

　　（2）应用服务独立部署维护，有利于迭代开发升级持续部署

　　（3）架构灵活支持多种技术实现

　　（4）有利于应用服务实现高可用性

　二、微服务架构不足

　　（1）对系统设计有必定要求，尤为是拆分技术应用服务接口

　　（2）致使系统实现复杂度的提升

　　（3）须要确保系统数据一致性机制

　　（4）致使系统维护要求和成本提升

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

---

  

3、框架设计原则

　　一、可扩展：支持不修改系统功能，按需扩展服务器资源。

　　二、高可用：支持分布式部署双机热备机制，知足系统高可用性的要求。

　　三、高并发：支持快捷扩张应用服务处理能力，提高系统处理能力，知足并发请求。

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

　　五、一致性：采用数据最终一致性策略。

---

 

4、框架整体设计

　　　　

                                                                                图1- 系统架构示意图

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

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

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

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

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

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

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

　　 

5、软件架构设计

      　　

                                                                                 图2- 软件架构示意图

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

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

6、结语

　　基础架构大体设计就这样，还须要考虑实施部署，能够考虑云平台弹性资源，再结合docker容器技术。

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

 

 

做者:刘蔡涛
出处： http://www.cnblogs.com/Andon_liu
关于做者：专一于微软平台项目架构、管理。熟悉设计模式、领域驱动、架构设计、敏捷开发和项目管理。现主要从事ASP.NET MVC、WCF/Web API、SOA、MSSQL、redis方面的项目开发、架构、管理工做。 若有问题或建议，请一块儿学习讨论！
本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面明显位置给出原文链接。
若有问题，能够邮件：568773262@qq.com 联系我，谢谢。

微信号：