本文只是做个简介，起抛砖引玉效果，希望能给大家一些启发（ps：作为一线码农，在工作中经常接触并使用这些框架，深深为其强大功能、设计思路所折服）
1. session框架
session大家肯定都不陌生，由于HTTP协议本身是无状态，前后两次请求通常是没有关联的，但由于一些业务需求，又必须让其有所关联（比如登录，不可能让用户每次访问一个页面都需要重新登录一次，那用户肯定会疯掉）
此时我们就需要借助session机制，将用户的一些信息存储在服务端，其主键jsessionid存储于客户端的cookie中，下一次用户发起请求时，servlet框架会根据jsessionid自动寻找关联的信息。
但随着互联网的快速发展，用户群越来越大，如何来存储、管理庞大的session信息显得越来越重要。
通常的作法是采用集群（多么熟悉的名词，ho~ho~），例如tomcat采用集群节点广播复制，jboss采用配对复制，但都严重影响系统的伸缩性，不能通过增加机器达到更好的水平伸缩，而且随着节点的增加，节点间的通信也更加频繁，势必会造成系统内耗加大。
webX框架的基于cookie的session可以有效的解决这个问题，将信息存于客户端浏览器的cookie中，而应用节点本身不保存任何状态信息。但要注意的一点是不同的浏览器对cookie的支持标准不一样，关于这块可参照之前的文章《浅谈浏览器cookie》。对于这个问题，我们的解决方案是“多值cookie”，一个组合键对应多个cookie值，可以有效将cookie的个数控制在20个以内，很大程度节省了cookie信息的存储空间，更多精彩可参考《Request context之session指南》
2. 缓存tair
缓存，主要是为了减轻对数据库的压力，使用场景非常广泛。有浏览器缓存、反向代理缓存、页面缓存、对象缓存等
tair是淘宝的一个高性能、分布式、可扩展、高可用性的key-value结构的存储系统。
非持久化：
mdb引擎: 只支持key/value，单机性能7w qps（测试条件：单条记录512字节，响应时间2ms内）
rdb引擎: 不仅支持key/value，还支持list/hashmap/set/sortedset等复杂数据结构。
持久化：
kdb引擎：采用了kyoto cabinet做为引擎，性能在2000 qps单台。
ldb引擎：采用了leveldb做为引擎，并且自带cache。服务器采用了ssd，性能在5w qps以上。
目前tair已经开源，开源地址：http://code.taobao.org/p/tair/src/
3. 服务化（HSF框架，dubbo）
服务化的核心就是解耦，将生产端和消费端有效拆分，借助于HSF来达成调用关联。使用系统的整体可用性、扩展性大大增强。
举个很形象的例子，一个业务开创之初，可能只有一个应用，但随着业务的不断膨胀，代码量也越来越大，无论后期开发还是维护带来的成本都是很高的，此时，从架构的角度会进行系统拆分，通过增加子域名的形式，借助于http请求，将不同的业务交由不同的系统来处理。
比如商品展示交由系统A处理；当用户添写一个购买数量，并选择好规格属性后，点击“购买”按钮，会将请求发送到系统B来处理， 无论从业务划分、模块定位、还是代码开发，都鲜明不少。
现在回到我们服务化的内容来，在服务化推广之前，底层业务通常是这样处理，如果你想使用部门A的业务（通常要数据库操作），首先要引入相应的jar包，尤其是底层的dal层的包（sql.xml ，接口，接口实现等），然后在应用中手动配置各种bean关系，可以说相当繁琐。当然如果只是配置一次，再繁琐也忍了。互联网千变万化，电子商务更是瞬息万变，业务变更相当频繁，代码频繁改动那更是家常便饭。想象一下，如果你的dal层jar包被十几个业务线所依赖，如果你想改底层的dao接口实现，你是不是需要这十几个业务线也跟着空发布一次，只是为了打包时能加载你最新的代码。
痛苦之大难以想象。幸好有了服务化。服务化可以有效将业务收扰到服务端，对外只暴露一个接口即可，如果你想用我的业务，只需做下简单接口配置即可，调用时，HSF框架会帮你找到对应的服务端，然后服务端会进行相应的业务处理，返回给你想要的结果，是不是清晰了很多。
4. 数据库拆分TDDL
现在是大数据时代，随便一个应用，动辄就是上千万的数据，数据库表示压力越来越大。分库分表成为业务发展的不二选择。
TDDL是淘宝开发的一套分布式数据库访问引擎。可以有效解决
a）数据访问路由：数据的读写请求发送到最合适的地方
b）数据的多向非对称复制：一次写入，多点读取
c）数据的存储自由扩展：不再受限于单台机器的容量瓶颈和速度瓶颈，平滑迁移
关于分库分表可以看看iteye上的一篇文章《淘宝下单高并发解决方案》
另外tddl也开源了，开源地址：http://code.taobao.org/p/tddl-dynamic-datasource/src/trunk/
5. 异步消息（notify）
主要是借助消息中间件，采用异步通信来达到系统的伸缩性，以最大化的对各个子系统解耦。
具体是采用同步通信还异步通信，需要结合业务来衡量，如果业务本身关联度较大，建议还是采用同步通信比较靠谱。
关于异步消息这块，之前有过简单整理《基于消息的分布式架构设计》
6. 非结构化数据存储 ( TFS,NOSQL)
并非所有的数据都是结构化的,比如一些配置文件，交易的快照等，一般不适合保存到RDBMS，更符合一种Key-value的结构；另一类数据，数据量非常大，但实时性要求不高，此时这些数据也需要通过另外的一种存储方式进行存储。
一些静态文件，比如各个商品的图片，商品描述等信息，这些信息因为比较大，放入RDBMS会引起读取性能问题，影响其它数据读取性能，也要和其它信息分开存储，一般的选择分布式文件系统。
随着互联网的发展，08年下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论，一致性，可用性和分区容错性三者不能同时满足，最多只能同时满足两个。
传统关系数据库采用ACID事务策略，更加讲究高一致性而降低了可用性的需求；但互联网应用往往对可用性的要求要略高于一致性的需求，这时候就要避免采用数据的ACID事务策略，转而采用BASE(基本可用性，事务软状态以及最终一致性)事务策略
目前此类产品有facebook 的cassandra,apache hbase,google bigtable等，非常适合一些非结构化的数据，如key-value形式数据存储，具有很好的水平伸缩性
一些静态文件，比如各个商品的图片，商品描述等信息，这些信息因为比较大，放入RDBMS会引起读取性能问题，影响其它数据读取性能，也要和其它信息分开存储，一般的选择分布式文件系统。
随着互联网的发展，08年下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论，一致性，可用性和分区容错性三者不能同时满足，最多只能同时满足两个。
传统关系数据库采用ACID事务策略，更加讲究高一致性而降低了可用性的需求；但互联网应用往往对可用性的要求要略高于一致性的需求，这时候就要避免采用数据的ACID事务策略，转而采用BASE(基本可用性，事务软状态以及最终一致性)事务策略
目前此类产品有facebook 的cassandra,apache hbase,google bigtable等，非常适合一些非结构化的数据，如key-value形式数据存储，具有很好的水平伸缩性
没有评论:
发表评论