业务现状+领导要求
　　1) 部署环境要求: 公有云，私有云，原有院内系统。三套环境，兼容部署，一套代码多环境支持。
　　2) 数据库要求：sqlserver，orcale，mysql要兼容，一套代码多库运行。
　　3) 性能要求：可扩展行好，性能高，水平扩展能力强（加机器就可以增强性能）。
　　4) 开发要求：简单，容易，大家上手方便，文档齐全，无需关心底层性能及实现。
　　5) 运维要求：部署快，最好一键运行，无部署环境问题。
　　6) 架构要求：架构清晰，简单；组件化，模块化，微服务化；外部接口兼容，不同底层实现配置切换。
　　1）部署环境要求说明
　　目前的部署环境主要有公有云，私有云，原有院内系统以及一些常规的业务演示。
　　公有云: 目前考虑的有阿里云部署（线上），其他云部署（合作项目，线上），要求性能极好（应用可平行扩展部署，以便性能达到业务发展的承载能力）。
　　私有云: 目前考虑的是原有的院内系统升级为私有云的形式部署整套云服务业务（整套基础服务将打包成虚拟机镜像方式部署），要求云服务性能可以适应极低的硬件配置（院内前置机硬件水平不佳），也能正常运行。部署的情况很多（业务的主要场景），故要求技术支持能够非常方便的部署（一键部署或者安装包）及问题的排查。
　　原有院内系统：原有院内系统可以考虑升级为私有云的方式部署，部分新的技术方式（如ef，activemq等），也可以使用，底层的一些实现能够相对兼容（如数据结构）。但是暂时也不做过多的考虑。
　　以上环境，业务开发人员需要做一些区分，以便运用相应的技术（原有院内系统没有升级私有云，就无法正常使用大部分基础服务相关的功能）。一套代码要兼容多套环境下的部署和正确配置，便于业务运行。
　　@解决方案
　　采用虚拟机镜像的方式部署业务和基础服务，以整套镜像版本提供业务版本，简化安装，简化运维，一键部署。
　　未来所有业务支持通过安装包脚本的方式部署组件，部署服务，部署应用到基础服务等，否则难以应用多种环境，不同兼容性等情况。
　　基础服务镜像会以开源的形式验证整体的兼容性和稳定性，通过开源反馈改进镜像版本的稳定性。
　　2）数据库要求说明
　　目前的数据库环境主要是sqlserver，（但实际公司场景：有些院内特别要求及目前公司领导要求）必须支持orcale，mysql的数据库平滑切换。即一套代码兼容三种数据库的操作方式，尽可能少的方式或者通过修改配置的方式，一键切换不同数据库。同时要求必须支持多库操作（分业务库和核心业务库等），性能相对稳定。使用要简单，开发容易上手，资料文档要多！
　　@解决方案
　　采用entityframework框架，二次封装插件。ef框架性能其实并不高（或者较差，未来的未来肯定是一个数据库的支持方向，但目前比较遥远），但是能够兼容多种数据库，通过切换不同驱动dll库，可以一套ef linq代码，多种数据库，多库支持。国内外.net通用流行的开源框架，微软开源支持，文档众多，极易上手使用。在业务开发的前期和中期，将会一直保持使用该框架；在业务发展的后期，将会考虑使用纯sql编写数据库操作代码，且业务数据库考虑深度的拆库和分表。
　　3）性能要求说明
　　1. 要求业务和底层基础服务，具备架构上的扩展能力，通过加机器，升级硬件资源提升程序的性能。同时底层基础服务必须支持高性能，极强的水平扩展能力（分布式扩展能力），这样基于基础服务研发的业务，才能天生具备分布式特性，天生具备性能扩展能力。
　　2. 实际公司的私有云环境的硬件性能其实不高，而开源的一些服务或者第三方解决方案往往对单台服务器的性能要求其实会比想象中的偏高，更别提一些配套的相对复杂的高可用方案，不太适合实际业务的部署硬件环境。故在具备研发能力的情况下，采用自研的方案提供更低配置兼容（1核2G的硬件服务器）的基础服务能力（同时自研框架又要能够兼容第三方框架，这样以便在不修改业务代码情况下就可以在更高性能要求的公有云环境中大规模部署）。
　　4）开发要求说明
　　目前公司内部的开发人员的技术水平很低，对基础服务的一些相关概念不了解，相关的组件普遍知识（如消息队列，任务调度，redis）接触不深（有些人自身学习欲望也不强），短期乃至长期内不容易改变现状。
　　@解决方案
　　1. 虽然可以通过培训等手段进行培养，但是基础服务sdk层面更要提供一些非常简洁精炼的接口调用，屏蔽大部分实现细节（对技术感兴趣者可以看开放权限的源码）;
　　2. 同时提供使用demo和不断完善的技术文档（知识库体系），应对各种环境使用的问题自查，解答，知识沉淀和分享；
　　3. 通过配置中心，连接池，线程池，监控平台等手段，提供人工和自适应的性能调优，性能监控和分析，性能优化建议等（性能监控这块需要不断完善和监控体系建设）。
　　4. 剥离性能和业务实现，沉淀与性能相关的技术细节为基础sdk或基础服务平台， 通过底层研发人员不断监控和调优性能，提升整个业务平台的性能和总体稳定性。
　　5）运维要求说明
　　目前公司的业务方向是大量的私有云推广，意味着一些技术支持人员（工程部）在现场实施，每个现场的环境都不一样。现实情况是运维文档很粗糙，单个基础服务部署较艰难（如果使用第三方开源项目或者解决方案的话更加痛苦，有些开源项目专业人员部署都要好多天，更别提高可用和复杂的部署环境配置和调试），技术支持人员水平较低，运维人员人数有限等等，现实很残酷！
　　@解决方案
　　1. 所有基础服务都安装配置完毕后，打包成一个私有云镜像，以虚拟服务进程的方式提供整套的私有云基础服务（理念: 云即服务，服务即云，一键部署，处处运行！）
　　2. 业务提供两种部署方式：镜像方式和安装包方式。镜像方式类似云服务的方式一键部署，安装包方式须提供自动安装脚本和手工部署文档，还有版本升级包等方式，简化安装步骤。
　　3. 建立运维部署流程规范和知识库体系，以应对各种复杂情况。
　　6）架构要求说明
　　公司业务开发人员技术能力偏下，同时业务的迭代进度要求高，没有足够的耐心了解沉淀技术知识。故而整体技术架构需清晰，简单，独立性明显，容易理解和区分。出现问题需容易定位问题和排查，性能问题尽量不要让业务开发人员关心。框架使用足够简单，技术文档要足够齐全，配套的架构方案实施需要有相关人员跟进，建议及监管，让业务开发从技术细节中脱离出来，从而加快业务迭代速度。
　　@解决方案
　　1. 所有基础架构需微服务化和sdk化，（同时避免sdk版本混乱，无论基础服务功能有多复杂）仅提供一个统一的sdk解决方案，配套相应的技术咨询人员和技术知识库。
　　2. 基础服务架构需概念清晰，简单，能够用几个字就能表明用途和使用场景，容易在业务开发中推广，落地使用。
　　3. 所有基础服务架构设计上需保持独立性，组件化，模块化，尽量降低耦合，便于扩展，调试，性能分析，优化。（以及未来组织架构上研发人员扩充，可以单独深入负责某块基础服务的演变，无需了解整体）
　　4. 统一公司所有基础框架的使用和第三方框架的使用规范（接口即规范，Sdk即规范），同时与公司基础服务概念相同的公用第三方框架的使用，通过自研接口（适配器或者桥接模式）进行具体第三方框架实现的隔离和兼容，保证部分第三方框架的选择和自研框架的演变，对于业务开发人员使用透明，无需更改代码（甚至在线无缝切换）即可一键切换（通过配置中心）到不同实现。（如消息队列和tcp通信服务等）
　　总结说明
　　架构设计总为业务而服务，并非技术而技术；而业务现状和公司的要求往往是让架构设计最为纠结和取舍的，特别是考虑人员，资源，成本等各方面的限制，选择一个可行的方案。云服务化是公司总体坚定的业务方向，基础架构的沉淀和分布式的开发避无可避（而非传统业务代码拷贝到外网服务器上就是云服务了）。架构设计首先会以架构布局为优先，稳定性为次之，性能为更次之，同时必须兼顾到现实的运维情况；而后待业务发展，各方面相对稳定后，逐步推进优化，性能提升，架构演变乃至推翻部分重建。