曾几何时，企业级软件是一个非常高大上的名词，而难用是后面的潜台词，从部署到配置到使用，非常的受诟病，但是没办法，在软件开发不那么成熟的时代，能够有能力组织开发出如此复杂的软件的就那么几个公司，能够做出来已经很不错了，加上采购者和使用者完全是两拨人，使用者的话语权太低了，所以以用户为导向的重要性虽然在产品开发的过程中被重视，但是视角完全是错误的，重点完全在功能的完整性、多样性和灵活性上。当互联网真正崛起，SaaS被广为接受，服务化被广泛采用后，我们才发现他们的玩法不一样了，因为直接面对的是最终使用者，最终使用者的口碑传播效应得到了极大提升，以使用者作为真正用户的视角才被纠正，所以各种讨好最终使用者的特性才被重视起来了，早期一个很重要的概念就是傻瓜化，这个，乔布斯的iPhone也是居功至伟的，但是我更愿意叫这个为智能化，伴随而来的还有极简化，核心思想就是尽最大可能减少用户的思考和使用门槛，上手就能够用而且用的比较顺畅。由于我以前也搞过自己的社区，深深知道这个有多么的重要，而很不幸的是这么多年都在大公司，很多思想并不被接受，终于，从前几年开始，这些风终于刮到了企业级这个漆黑的领域。从3年前做的一键升级整个集群，使得原来一个40台节点集群的升级时间从7天缩短到8个小时（大部分其实是升级准备及数据库，服务器升级半个小时内就可以搞定，并行的），而且基本不需要人工干预（除非客户有自己的定制化配置），为此Support的头头还专门写信表扬过，到现在，新的产品的一个极大的重心也是在智能化和极简化上，包括安装和升级，总算开始和自己一贯的思想理念一致了，特此纪念下。。。
解惑
解己之惑，解人之惑
分类：设计 (第1页共3页)
前段时间接手了系统的升级功能，看了安装和升级的部分，关于版本的处理简直不能直视，因为全部是hard code的，每次版本有任何修改都需要修改脚本，我接手后重写了升级部分，但是没有想到最后还是栽在了版本问题上，因为我调用了一个系统原有的升级脚本，而那个脚本需要传入包的版本号，所以第一个升级包中我也hard code了那个包的版本号，谁想GA的前一天友队升级了那个包，我们的Build工程师更新了那个包，改了相关的脚本但是没有更新升级部分，更大的集成的时候就出问题了。。。真的是怕什么来什么。
进入这个新的项目后学习到的一个很重要的概念就是Role了，这个Role和我们平时的用户的Role是不同的，而是Service或者Component或者Instance的Role，怎么讲？其实就是一个东西，具备多种功能，你可以让它同时做那些事情，在高负载的情况下，你可以安装很多个，然后让不同的东西承担单独的功能或者几个功能。
说白了，这个不神秘，就是在系统设计的时候可以让某些功能启用，某些功能不启用，好处是什么呢？你可以针对系统的负载特点安排Cluster的配置，有些组件的负载更重一些，那么就多安装一些机器专门负责那个功能，也就是更加灵活的在各个层面可以实现负载横向扩展或者Cluster。
举个实际的例子：
微软的Exchange大家想必都用过，Exchange的功能也是可以划分Role的，你可以安装很多个Exchange，但是安装的时候选择这个Exchange的Role，可以是专门负责收邮件的，可以专门负责邮件的过滤，可以专门负责客户端访问，可以专门负责Mailbox，等等，想详细了解的朋友可以看看这个E文。
当然，这个Role其实有比较正式的名称，就是Server Roles。
昨天和Bruce聊天谈到这个，其实这两个概念并不神秘，SaaS就是Software As A Service，而PaaS就是Platform As A Service，这两个概念目前做得最成功的就是salesforce了，因为salesforce的成功，他们把salesforce背后的硬件基础设施和通用的软件基础设施抽取出来，变成了force.com，也就是PaaS。当然，在这两个概念之下又有人搞出了很多aaS：
如果一个公司想推PaaS，那么如果他自己没有一个成功的SaaS产品是不可能的，因为没有可信度，就像Google推广GAE很有底气，Salesforce推广force.com一样，他们有自己成功的platform，而且已经被自己证明是真实可行的。
现在也已推出的PaaS平台，除了force.com和GAE外，还有一个比较有名的就是Amazon的EC2，但是个人觉得EC2只能算是HaaS，因为没有强有力的软件平台以及公共基础设施，还是停留在硬件虚拟化的层面。
推荐另外两篇文章：
当今云计算平台之肤浅比较(EC2, GAE, GoGrid)
Cloud versus cloud: A guided tour of Amazon, Google, AppNexus, and GoGrid
越来越感觉各种系统在构架的时候进行了无状态化，因为在大规模系统中，要更好的进行负载均衡以及集群，无状态的服务是最好的选择，因为每个请求都是独立的不依赖上下文的，任何一个服务节点的崩溃都不会影响整个系统，而且要增加系统的负载能力也很容易，增加更多的服务节点就行了。从GAE默认不包含Session我们就可以看到一些这样做的好处。而且Context或者Session之类的东西也比较好弄，也作为一个服务，根据某个UUID或者session id之类的东西就可以进行存取，如果某些服务真的需要session，那么可以到session服务取。但是这样做会导致session的那个服务成为系统的瓶颈和薄弱点，也会导致那部分的负载均衡和HA更难达到。结合客户端的RIA倾向，更多的Session和Context保存在客户端，利用客户端框架在发起请求的时候把需要的内容发送给服务器端。
呵呵，原来自己也可以搭云玩了，而且是Java的云，这是apache下的开源项目，是根据google发布的一些论文构建的，虽然根据这位老兄的实验，在集群环境下的性能并不是特别理想，但是还是值得一试的，毕竟代表了最先进的IT技术之一嘛。最后提一下这个Hadoop中文研究院，有兴趣不想看因为的可以看看这个网站。
今天和美国的架构师以及美国那边负责UI的consultant的头开会，从结果来看，感觉我们已经不是SaaS了，因为从他们考虑我们的Service的角度看，我们的Service基本上是in process的调用，都不太关注远程调用或者web service调用的可能性了，虽然架构师在我的提示下要求考虑这种远程调用的可能性，但是in process调用还是被优先实现。当然，我们的服务对外当然是SaaS的，因为用户不会关注我们的内部实现是否可以远程调用，但是这样的架构让我感觉不到SaaS的精髓。
可能是我对项目的期望太高，亦或者我们项目还在起步阶段，很多东西还没有最终确定，但是目前的情况让我还是有些不快和不安。
今天看到的，觉得不错，转帖下备忘：
1、关注人——他们的生活，他们的工作，他们的梦想。
2、每一毫秒都至关重要。
3、简洁是有力的。
4、吸引新人，诱惑专家。
5、勇于创新。
6、设计放眼世界。
7、当下与未来的业务并重。
8、让人眼前一亮，又不会心有旁骛。
9、对得起人民的信任。
10、融入人性接触。
现在正在使用spring+hibernate+struts完成一个项目，在做这个的过程中发现我们很多时候的工作都花在了基本的可以代码生成的
javabean创建、form创建，页面创建，action创建，DAO创建上，其实这些工作都是可以不用人工完成的。看了一下appfuse，感觉使
用起来还不是很方便，打算自己做一个简单的生成器，初步计划是使用xstream+freemarker，系统的字段、页面、action什么的简单的写
一个xml文件，然后写一些代码模板就可以了（包括javabean，hbm.xml，DAO，Action，Form，JSP以及struts、
spring和validation的基本配置），另外还会包含一个基本的空白工程，有一些共通的功能。如果是业余时间做的话估计需要一个月左右的时间。
等手头的这个项目做完就开始做了。
上次提到要重写JR的系统，其实最想做的还是底层的框架。
这几年看了或者用了很多东西，最开始了解并深入学习的就是jive，以后还有junit，spring以及hibernate，都是让我感觉比较好的东
西，然后在工作的过程中看到别人设计的各种框架，感觉都有很多优点，但是使用起来又不是那么舒服，因此想总结一下自己的经验，看看能不能做一个让自己满意
的系统。
其实做这个系统的最开始的出发点就是嫌各种东西比较麻烦，第一就是代码重复，第二就是需要一些学习成本，第三有些不太直观，第四就是麻烦。
我考虑的第一个出发点就是减少配置，使用规则替代，这样可以避免一些前后不符的情况，对于以后的维护比较好；
第二就是简单，使用的技术的门槛尽量低，类合理的少。
第三就是尽量直观易用，尽可能提供一步到位的功能。
系统的核心是javabean，或者是POJO，他是数据库操作和页面表现层的核心，数据库的内容可以直接提取出来变成javabean，页面也可以使用
javabean完成数据表现，web请求中的参数直接填写到javabean中，数据库的持久不是自动的，但是只需要调用API触发一下。
目前系统的各个部分的设计还没有考虑好，有些甚至还没有确定能否解决，需要慢慢的细化，也许需要找几个人一起来做。
© 2024 解惑
本主题由Anders Noren提供 — 向上 ↑