b2c项目基础架构分析（一）

我最近一直在找适合将来用于公司大型bs，b2b b2c的基础架构。

实际情况是要建立一个bs架构b2b、b2c的网站，当然还包括wap站点、手机app站点。

一、现有公司技术人员现状：

1、熟悉asp.net页面级开发、页面级处理的后端人员。

基本特点：掌握小型单站、单页的相关开发技术。

技术熟练度为：asp.net原理基础、asp.net webform控件中等、jquery基础、js初步到基础、sql基础到中等。

面对大型站点可能存在的弊端：

• • a、不熟悉大型环境的架构；
  • b、对站点、页面在大型站点吞吐量下可能面对的问题应对能力有限；
  • c、因为并不使用一些高级的页面以外的语法和库，涉及到这些功能的编写基本能力比较空白，特别是比如io、队列、异步同步这些协调性要求高的操作，不习惯设想考虑恶劣情况；
  • d、长期依赖sql层来处理业务逻辑，缺乏对大型站点可能涉及的技术认识和熟练程度；
  • e、后端长期使用三层所以结构比较明溪，前端就像经理们说的一样，开发方式混乱，造成难以维护，和bug重复等问题。

2、熟悉jquery、css、html能切图的ui人员。

• a、作为页面级效果、特效、界面的制作能力已经足够；
• b、在建站过程中可能太多任务化目标化，如果可能的话，应该更积极地参与view层的jquery 、js的开发工作；
• c、应该还缺乏大型站点整站ui、css、js的规划和布局能力和技能。
• d、在大型站点的情况下，优化多js、css文件的发布合并、压缩，可以有效的降低基础流量消耗和连接数压力；

3、要应对大型项目的测试，我认为公司还没有起码的测试团队，也没有开发团队里的明显的模块测试、相互测试、以及明显的迭代机制。

• a、我不那么熟悉公司的测试组，但是测试组似乎是在做黑盒测试，这个在大型项目里说要栽跟头的；
• b、缺乏模块级、代码级白盒测试的机制；
• c、一线开发似乎很缺乏多人互助，互相检查代码的情况，靠开发者个人自己，自管一滩这在大型项目开发的时候势必会引发一系列的问题；
• d、前端没有使用可多人维护的分层的明确的软件结构，应该引入相关前端层面的分层框架结构，来使得前端风险更可控制；

4、数据库和运维人员。

• a、公司应该是拥有足够能力的微软操作系统、数据库和webserver产品的运维人员，但是这在长远来说，是不够的；
• b、假定公司因为原有人员大量.net技术为主、加之微软最近对.net的跨平台和种种开源，将公司将来的大型架构定义在linux平台基础上，那公司就需要有一定量的linux运维人员；
• c、现在的数据库管理相对松散，甚至可以说不存在都不为过，大型项目中可能涉及的环境从简单的测试、开发、生产三个可能是以服务器台来计算的环境，将演变成以前端web和入口服务器集群（入口层）、中间业务逻辑处理中间件集群、缓存服务器集群（在线业务层、缓存数据层）、后端活跃热数据的数据库集群、历史数据仓库（在线数据层、近线统计分析查询数据层），并且可能生产环境和准生产环境都要长期互相独立并且互相代码数据迭代似地上线和备份，以保证上线以前有足够的测试机会，这句需要同时有内外网2个环境集群，可能为开发还有另外准备第三个或者从内部集群里开拓出一部分来给开发使用。
• d、这就会需要相当一部分的除了基础linux维护人员，可能还需要各种运维方面的技能 应该会涉及所使用的数据仓库软件（hbase）的部署和维护、sql数据库集群架构（准mysql集群、包括mysql社区分支版本MariaDB、相关集群软件比如mycat）的部署和维护、缓存数据库集群（redis集群、mencached集群，比如redis官方3.0集群的配置或者更简单的redis集群代理软件Codis等）的部署和维护、前端web服务器（可选的有国内不开源的一体式的.netweb方案jesux、Apache挂mod_mono或Nginx挂mod_mono以及将来的微软官方的跨平台webserver端）和.net环境（第三方。net实现的mono、或者将来的微软官方的。net core跨平台运行时环境）的部署和维护；
• 短期可以由开发人员里熟悉以上内容的人来管理，长期肯定是要配备的；

二、整体软件架构思想：

由于公司的b2c、b2b业务构想还只是雏形，所以只能够大概设定一个软件架构的思路：

首先，业务逻辑上，要及时积极定义出历史数据，将其及时移动到数据仓库层级，这样能大大降低强事务sql数据库层级的压力以及提高该层级的性能表现；

然后进行业务拆分，将不同业务操作类型从入口层以后分配到不同的业务处理集群，这样可以降低其后每个集群的压力，提升性能表现；

凡是可以不必实时的操作，一定要区分出来，采取队列处理机制，可以预处理的行为积极进行预处理；

如果可以的话，将sql层面的表结构就考虑好，多插入少更新，积极地努力回避事务死锁问题；

Linux Web .net 架构：

• • http反向代理：最前端使用Nginx之类的http反向代理服务器集群和cdn加速网站响应，静态的内容的请求可能因为这一层就被处理掉了大部分；
  • 性能分析、监控：这中间可以插上各种日志、分析性能、监控等各种服务套件，这是linux的常规优势；
  • 负载调度：Nginx之后是负载均衡调度服务机制或服务器集群，好在现在云服务器都有这个服务，很简单；
  • 应用程序服务器集群（分业务、分服务）：然后是.net的web server集群，并且应该根据业务拆分和服务拆分为多组集群，说白了就是这些应用服务器有很多不同业务分工的服务器端代码在运行，每一份代码应对一种业务需求或者服务需求，然后每一份代码有多台服务器视为一组的区分开来，每个服务、业务逻辑处理上动态负载均衡（也就是A应用服务器集群处理一些类型的业务，b可能处理另一些类别，然后c可能提供一些服务类型的给自己或外部使用），技术上。.net在linux下的应用程序服务器可以选择使用Nginx（这时候其作为普通正向http server）或者Apache来配合mod_mono，开始可以考虑用国产闭源asp.net容器实现的jesux，我因为亲自考察了官方技术人员和相关社区的情况考虑可能的话做大了以后不用它，闭源、文档混乱缺乏、开发者也看似不够正视生产环境用户，是国产软件的诸多问题，虽然初期jesux是简单强大的容器实现；
  • 消息队列服务器集群：常见跟在应用服务器后面的有消息队列服务器，提供供前者处理的跨服务器的稳定的相对缓慢的应用程序外部队列；
  • 搜索引擎服务器集群：搜索在web是家常便饭经常也是用户体验的重要一环，所以最终难免有搜索引擎，作为数据库内容的一种入口提供方式；
  • 多种缓存服务器集群：
  1. 1. 又分内存比如用于告诉内存缓存的memcached集群、同样是内存 速度不亚于前者又带硬盘序列化的redis集群，内存nosql主要指的redis，mc只能用于可丢失的缓存用，而redis可以起到很重要的作用，成为完美的硬盘数据库和用户操作响应直接的中间加速器，由于redis带硬盘序列化，所以非关键增删改都可以基于redis这个内存数据库处理，如果配合使用上比如Codis这样的redis集群代理入口的话，单机的内存限制就在也不是限制了，因为redis单线程模型可以使用大量内存足够cpu较差的微型瘦服务器来参与在集群里，得到一个性能很好的全内存性能带硬盘备份的缓充容器了，
     2. 以及nosql基于优化的硬盘读写引擎比如谷歌支持tb级海量数据的leveldb引擎、facebook的RocksDB引擎据说比谷歌的那款数据多的 时候性能更佳的诸多硬盘nosql数据库产品，国产的有主要基于leveldb的ssdb、和主要基于RocksDB的ardb，硬盘nosql数据库的特点：数据相对内存nosql的稳定安全（除了写瞬间出现问题的几率高点，就是要么写入了，要么没能写入丢了），读写性能理论上有机会配合多服务器ssd硬盘得到接近内存nosql的机会，关键属性是容量没有内存的限制，有很适合模糊查询，当然实时性要求不能太高，适合用来存用户日志等量大但是重要程度次级的信息；
  • 文件服务器：web难免有不少的静态图片，某些业务逻辑下用户上传的附件文件可能更不少等，一般需要单独的文件服务器群来承载，虽然cdn可以分担掉不小的图片方面的压力，还是要应对用户随机的上传、下载问题还是得用方案的，linux下分布式文件服务器方案方便又多样，比如NFS、windows兼容协议的samba、FastDFS；
  • 分布式数据库集群：我本来以为我找不到方便的支持强事务的读写分离 高可用 分裤分表的开源免费方案，我本来都打算放弃数据库这一层之间跳到用大数据数据库去了，直到我发现继承了淘宝mysql分库分表方案的cobar的mycat方案，该方案已经社区很活跃，国内已经有很多大公司使用，是一个可以视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群；
  • 大数据层：这里hadoop好像是目前稳定文档多的唯一选择，作为数据库使用的话，基于hadoop的hbase几乎是必然选择，国内外很多大互联网公司的很大一部分数据都存储在hbase上，可以说是hbase承载着今天的互联网；

架构小结：

上面就是我觉得在业务逻辑不那么清晰的情况下，我为将来的业务承载准备的大型bs的基础数据技术硬性构架的技术选择，主要的来说由http反向代理打头 后面跟上带负载均衡和业务分拆、服务分开的多路应用服务器集群，然后配上内存nosql集群应对最高速要求的热数据，后面跟上强事务sql数据库集群和也有高速查询反应的数据仓库级数据产品hbase，短期可以在其中混上文档型数据库比如MongoDB来应对短期内的多变需求，因为文档数据库是不必定义复杂的字段架构的，长期来说文档数据库的意义有待商榷，因为具资料mogodb的高并发连接情况下的速度始终不敢恭维。

应用程序层使用linux版本。net第三方运行时实现mono，并不算多冒险，国外世界前200位的IT网站有若干曾经多年使用mono+linux方案，缓存层redis几乎是唯一的选择，而选择Codis这样一个集群产品，是因为在开发的时候你可以大可不必挂上Codis，Codis是完全redis协议方式的，所以应用程序方面完全不会有任何感觉的；同样MyCat也是这样的一款产品，、它自己内部用它自己的方式协调后面的多台服务器的读写，你只需要把他当作基础的mysql协议的数据库那样去对待即可，至于hbase长期来说必然使用，短期你甚至可以无视它，等到你用到他了，并且按照我说的那样在历史数据的方面用它，你也自然不会觉得有什么难度，说到底hbase的配置部署和硬件质量和数量这些要求才是问题，使用的本身并没有什么难度。

未完待续......

原文：http://www.cnblogs.com/sfissw/p/4506605.html