将框架遇到的问题和框架升级设计进行记录。
一、背景&问题
之前框架是一个基于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