业务现状+领导要求
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. 通过配置中心,连接池,线程池,监控平台等手段,提供人工和自适应的性能调优,性能监控和分析,性能优化建议等(性能监控这块需要不断完善和监控体系建设)。
&nb
