1.当前系统技术框架
应用系统：单体架构，网页版管理中心、用户中心、官网使用asp.net webfrom (.net framework 4.5)，对外开放API为asp.net web api 2.0 (.net framework 4.0),操作客户端为WPF框架（.net framework 4.0）。
数据库：SQLserver 2008 阿里云RDS版、MongoDB（2.4.2单机版）
服务器：阿里云Windows Server 2008数据中心版
2.当前系统面临的问题
1. 业务数据（订单、费用、操作记录等）持续增长单表数据压力大，影响操作效率（查询、入库出库、扣费、数据导出）
2.系统跟新发布对正在使用系统的用户造成影响（如跟新期间有订单的操作）
3.系统配置文件无法动态配置跟新，测试环境配置环境容易因误操作更新到生产环境
4. 现单体架构多处理中心升级难度大，不同地域连接同一台服务器的速度不一样
3.升级解决方案
1.原管理中心、用户中心、官网不变保持不变（不能影响当前业务）
2.增长序列使用的MongoDB数据库独立出来（id生成、单号生成序列），统一序列管理（适用于分布式系统），后期做成分布式，按分区来构造id,单号等。
3.多处理中心独立出来，使用微服务架构重写处理中心，处理中心操作客户端使用WPF，处理服务采用微服务API。
4.业务数据、基础数据还是使用现有数据库（于当前业务不冲突，前期减少工作量），暂时不需要为每个服务用单独的数据库
5.使用Redis做缓存，现有系统缓存使用MongoDB做全局缓存，每个Web系统使用一个全局静态属性做系统缓存数据，使用微服务后这种模式会导致每个服务都有一个静态属性的内存缓存，导致内存暴增，也不利于缓存的统一管理，而Redis是内存型数据库，速度快，同一个处理中心缓存统一管理。
6.使用MQ分离出日志处理（分离影响运行效率的组件，使用队列来处理），日志文件不再保存在当前系统目录先，独立出一个日志处理程序。（后续再做升级、重写一份到MQ处理日志的帮助类，MQ暂定ActiveMQ）
7.客户端升级至.net framework 4.5或以上,能使用异步方法的地方尽量使用异步来处理，提升处理性能。
多处理中心微服务架构图
4.技术选型
目前市面上使用的微服务框架主要有Spring Cloud、Dubbo、Service Fabric、Steeltoe OSS
Spring Cloud：一整套的微服务框架集合，相当于一个全家桶，集成了微服务所需的所有组件，使用HTTP协议通信，Spring Cloud本身不是一个框架，是一个统一了各个组件版本的集合，国内使用的还算比较多，且文档资料比较多。
Dubbo:阿里巴巴开源的一款分布式服务治理框架，支持dubbo、rmi、hessian、http、webservice、thrift、redis协议，但作为一个微服务框架还需要整合其他组件，国家中文资料较多，
Service Fabric：微软开源的一个微服务框架，使用C++开发，目前资料比较少
Steeltoe OSS：一款.net 的开源微服务框架，兼容Spring Cloud的服务注册。
还有一些其他的框架，如Surging（资料较少，不是完整的一套框架），Ocelot（.net core平台的API网关）
综合比较发现没有一个纯.net下的比较好的解决方案，最终方案定为：Spring Cloud（java平台）+Steeltoe OSS （.net core 平台）
1.服务治理
微服务框架：Spring Cloud,版本Finchley.SR1（一个开源的java的微服务开发组件集合）
注册中心组件：Eureka Server
API网关：Zuul
断路器：Hystrix
配置中心：Apollo (携程开源的java写的配置中心阿波罗，有java及.net的客户端)
2.服务提供者
使用.net core 2.1 web api 来开发
服务注册（Eureka客户端）：Pivotal.Discovery.Client （Steeltoe的一个服务注册组件，.net开源框架）
3.基础框架
缓存：Redis
日志：MQ处理
ORM：Dapper
客户端：WPF
ID及增长序列存储：MongoDB
4. DotNet开发环境
IDE: Visual Studio 2017 最新版本
web API:.net core 2.1
5. Java开发环境
IDE:intellij idea 2018 最新版本
JDK：1.8
Maven：3.3.9
Spring Boot：2.0.4.RELEASE
Spring Cloud：Finchley.SR1