公司技术需求备忘录

业务现状+领导要求

 

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通讯服务等）

 

总结说明

架构设计总为业务而服务，并不是技术而技术；而业务现状和公司的要求每每是让架构设计最为纠结和取舍的，特别是考虑人员，资源，成本等各方面的限制，选择一个可行的方案。云服务化是公司整体坚决的业务方向，基础架构的沉淀和分布式的开发避无可避（而非传统业务代码拷贝到外网服务器上就是云服务了）。架构设计首先会以架构布局为优先，稳定性为次之，性能为更次之，同时必须兼顾到现实的运维状况；然后待业务发展，各方面相对稳定后，逐步推动优化，性能提高，架构演变乃至推翻部分重建。

 

（以上文字分不一样时间段总结而成，未校验，不顺之处请见谅！）