服务设计 谈论1

我一直觉得只有符合业务需要的缓存服务才能够成功！
设计时考虑越一般化越通用的 越有可能失败

所以设计你的专业缓存服务吧！

前一段时间的思考：
设计一个缓存服务器（tomcat+spring(http remote invoker)），利用memecached做缓存！
所有档案和采集数据的访问通过此服务器访问！

对上层应用提供一个接口包提供业务服务！

客户服务器：web 2台：32G内存，2CPU（1CPU=4 core ，8个逻辑单元）

Stone() 10:49:21
对上层应用提供一个接口包提供业务服务！
我们目前也是这样干的撒

大蜜蕊(305132968) 10:50:22
老实说，我想设计的是一个档案按关系型数据库存储！
个性化的档案数据key-value；
对于采集上来的数据10年不变，直接存文件或者数据库表都可以

参考了NOSQL的部分思想
大菠萝( 10:50:33
大蜜蕊，问一下你上面说的设计是不是不能支持事务？

大蜜蕊() 10:51:16
我一直觉得只有符合业务需要的缓存服务才能够成功！
设计时考虑越一般化越通用的 越有可能失败

所以设计你的专业缓存服务吧！

大蜜蕊() 10:51:46
所以我的档案数据使用关系型数据库保证事物！
存在幻读可能

Stone() 10:52:24
我们倒是没必要搞的那么复杂
只是取出数据,给一些接口用于访问和存取缓存数据就可以了
大蜜蕊() 10:52:33
我觉得事务问题，可以专门问题专门调整服务实现，即可规避
大菠萝() 10:52:36
恩，memcached和关系数据库一起使用，事务支持是个问题
大阿汪<> 10:52:47
remote的性能会差的多
缓存还是要本地块
大蜜蕊() 10:53:04
大阿汪<>  10:52:47
remote的性能会差的多
缓存还是要本地块


现在看着WEB 32G内存，我们最多也就使用1.4G
大蜜蕊() 10:53:19
他们部署在同一个机器上
大菠萝() 10:53:16
remote缓存其实没有那么多的性能损耗
大蜜蕊() 10:53:34
而且注意是使用的localhost
大蜜蕊() 10:53:48
根本不会完全经过协议栈的
大菠萝() 10:54:23
localhost比写ip要快，是吗？
大阿汪<> 10:55:16
……
大蜜蕊() 10:55:23
localhost就是127.0.0.1
大菠萝() 10:55:52
机器actual ip
大蜜蕊() 10:55:59
Stone(16781578)  10:44:57
可能是设计的不够好
Stone(16781578)  10:47:37
因为数据类型的差异,某些东西无法去统一

针对这个问题，可以分开看：
区分类型：那些部分会变化、变化频度
再调整存储即可
Stone() 10:58:36
缓存很麻烦的就是查询,和写数据很难搞
大蜜蕊() 10:59:31
如果你对外提供服务，自己内部做查询呢
大蜜蕊() 10:59:40
或者直接使用NOSql
大蜜蕊() 11:00:19
NoSQL产品
大蜜蕊() 11:00:24
Apple = Service.getApple();
其他属性(生产地)
生产地 = Service.getAppleProp(Apple, 产地key);
Stone() 11:01:09
呵呵 是对外提供服务的饿
大蜜蕊() 11:01:31
至于查询，根据前面的原则，只设计面向业务的专有服务，不会完全支持通用的
大人兽(714524622) 11:02:14
顶一个
大蜜蕊() 11:02:15
List<> ret = Service.getApplesBy生产地(产地名，省份，地市等等);
大蜜蕊() 11:04:21
大家注意到没，各个所谓的NoSQL产品，他们只是在某个同类业务的方面才有成功的案例，而且所谓WEB2.0公司讲的成功的NOSQL应用都只说了产品
大蜜蕊() 11:04:50
实际上他们实际使用时都会做选择，那些使用那些不用！
大蜜蕊() 11:05:24
淘宝的开放平台，对外提供的服务，也是专有服务，么有提供类似的(X)QL给你使用吧！
大蜜蕊() 11:05:32
说完了
[Head First]Eko Hu<[email protected]> 11:06:05
google和亚马逊都用了noSQL吧
大蜜蕊() 11:06:23
这里我觉得思想很重要
大蜜蕊() 11:06:45
我对目前公司的数据分析后得出的一个方案雏形：

http://skzr-org.iteye.com/admin/blogs/774323
大蜜蕊() 11:07:39
http://skzr-org.iteye.com/blog/774323
大蜜蕊() 11:09:41
Stone()  10:52:24
我们倒是没必要搞的那么复杂
只是取出数据,给一些接口用于访问和存取缓存数据就可以了
大蜜蕊()  10:52:33
我觉得事务问题，可以专门问题专门调整服务实现，即可规避

根据CAP理论：
    * C: Consistency 一致性
    * A: Availability 可用性(指的是快速获取数据)
    * P: Tolerance of network Partition 分区容忍性(分布式)

同时一刻最多同时满足两个条件！
大蜜蕊() 11:10:19
所以为了事务也就是C，必然牺牲A或者P
大蜜蕊() 11:10:48
这就是说为什么要针对专门的业务应用采用专门的实现策略！
大蜜蕊() 11:12:11
以上是自己的一点思考，未在任何系统中实践过

欢迎大家拍我
大菠萝() 11:15:32
好多地方没太听懂。
从你博客上了解到的就是注重业务，而不是纠缠于数据库的增删改查上。
大蜜蕊() 11:17:09
是的
大菠萝() 11:17:26
。。。。
大蜜蕊() 11:18:03
当然了，因为我们的业务就是对
中等数量级的数据进行处理！

如果是小系统，数据量少，完全没必要N多设计的
大蜜蕊() 11:20:36
这两年一直想设计一个完全满足CAP的底层，看了NOSql才知道，根本不可能
大菠萝() 11:20:47
面向对象语言难道本来不就应该更注重业务吗？
如果是小系统，变化不大，用面向对象语言很浪费，还麻烦。大蜜蕊用的是面向对象语言吧？
大蜜蕊() 11:22:48

大蜜蕊() 11:23:39
一直用java的ssh
大蜜蕊() 11:23:47
现在很烦躁用h
大菠萝() 11:24:26
服务器不错哦，如果不是windows系统会更耀眼
大蜜蕊() 11:25:09
我是力推linux的
大菠萝() 11:25:33
看来你们领导很死板啊
大蜜蕊() 11:25:56
吃饭先
Stone() 11:44:22
linux
大蜜蕊() 11:45:34
大菠萝()  11:20:47
面向对象语言难道本来不就应该更注重业务吗？
如果是小系统，变化不大，用面向对象语言很浪费，还麻烦。大蜜蕊用的是面向对象语言吧？

我的观点是——设计模式才是隐藏在背后的本源力量
“业务过程”——这个才应该被设计，而不是设计对象，对象只是业务过程的静态化！
探索“业务”的过程，就会形成和发现“设计”背后的模式