【原创】面向企业应用的平台框架的思考

面向企业应用的平台框架应该是什么样子的？或者说都应该具有哪些特性（现在流行说features，而不说functions）？我也看了一些书籍，比如《企业应用架构模式》，不过它太老了，翻译成中文版时已经是2004年了。不过对于“古老”的“企业应用”或许十年也不算太老，呵呵。

十年前，提到“企业应用”那一定是高大上的（当然那时候还木有高大上这个词），但是到了如今（2015年）我总觉得“企业应用”这个词似乎从一个“褒义词”变成了一个“贬义词”。。。也许是我的错觉，但愿吧。

如今的高大上，当然是互联网、电商、大数据。。。其实，我们叫喊了这么多年来，也从事了这么多年的企业应用开发，真正意义上的大型企业应用，真的是凤毛麟角。回想一下，我们做的哪个企业应用系统的装机量（不管它是C/S还是B/S结构）达到了10万？甚至1万？哪个系统的并发用户超过5千？我想即便是我们做的Sony全球售后系统，可能也很难达到。

试想一下“找出2014年全年订单中，单笔成交金额最大的1000比”，这个题目对于我们通常的企业应用系统，对于Sony，和对于淘宝来讲，完成它的难度系数各有多大区别？这就是“规模效应”（胡乱用个词），一个很简单的问题，在数量乘以10000面前，就变成一个相当复杂，甚至不可能完成的问题。（我也不知道淘宝的DBA能否完成这个问题的求解，谁帮我@ 他一下？呵呵）

举这么个例子，无非是想说，和互联网/电商这些用户量最起码上千万的应用系统比起来，我们从事的企业应用，其实都是小Case。以至于我做了十几年企业应该，逐渐感觉自己是井底之蛙了。
（当然，不要拿电信系统来反驳我，我没说所有的“企业”都是小企业）

软件是什么？连侯耀文先生都知道是 程序 和 存储，或者我们说是 算法 和 数据结构。和BAT不一样，做“企业应用”的，面试或笔试的时候，不会考你很多的算法题，中小企业应用中也用不上什么高大上的算法，递归、快速排序、归并应该就是拿得出手的算法了。所以“中小”企业应用中，能需要码农们注意的也就是树结构了，而且还很有可能只局限于DB结构。

所以，在企业应用中，“好的DB结构就等于成功的一半”这句话非常合适。那么我们今天想要聊的“架构模型”又有何用呢？或许我们把它理解成多个features的堆积体，就更容易理解了。通俗的说，具备了1-2个通用功能叫方法，10几个叫工具，20-30个叫类库，上百个就可以叫架构了。呵呵，不要扔鸡蛋哦，走下神坛它就是这么个玩意。

“把大象放冰箱，拢共分几步？”不知道的话，可以去问宋丹丹。我们借用一下这个Breakdown的思想，用类似WBS的方式分解一下一个面向企业应用的架构都该具有哪些features，分三步说是：表现层、逻辑层、持久层。

我想看这篇文章的人应该以“做后台”出身的为多，因此我们倒着说这三层，先说持久层。

1. 持久层
   持久层就是要把内存中的数据持久的保存下来。广义的说，可以保存到DB中、磁盘文件、闪存文件、甚至古老的磁带机中。然后在需要它们的时候在“读”回来。当然对于我们“企业应用”来说，就只（或者95%以上）考虑DB就好了，而且仅限于关系型数据库。

   什么NoSQL？与我无关，俺们大企业应用，都是高CRUD的事务性操作为主。企业应用吗，基本都是不差钱的（当然系统开发费用上除外），所以不要跟俺们提什么互联网企业都用几百台MySQL并行了，俺们就整1-2台Oracle就行了。俺们花了钱了，有啥问题可以找Oracle的砖家们来，弄一堆MySQL俺们玩不转咋整啊？所以，企业应用的数据库，基本上都是Oracle或者SQLServer。

   既然说到数据库，那就有很大一块是DBA要考虑的工作。从ER结构到分布式拆分（分布式我建议你去搜索一下《大型网站架构改进历程：存储的瓶颈》），从OLTP到ALTP再到BI分析...各种各样的优化手段：数据类型、主键、索引、池、文件系统、SSD...这里面要深入能有几十个关键字，任何一个关键字都是一门学问。（所以当你在简历上看到一个3-5年工作经验的求职者在数据库一栏填写的是“精通”的话，那么他/她的其它技能的自我描述基本都可以打个2折了。）

   和数据库相关的还有，连接池、缓冲区、ORM。连接池和缓冲区基本上就理解为一些配置参数的优化吧。ORM的问题要看整个架构的大环境了，是B/S结构还是返祖的C/S结构，是Java还是PHP还是微软解决方案。（别跟俺们提什么Python和Ruby，跟俺们企业应用不沾边。企业应用不是个人英雄主义，战线长、人员流动性大，你来到一个公司很可能是从半截进入一个项目的，当这个项目还进行到一半时，你可能就已经离开这个公司了，因此企业应用要使用大众化、“低门槛”的技术，各种级别的码农要通吃。）

   我们以Java平台为例，SSH/SSI（SSM）当然是最大众化的，ORM自然也就是在Hibernate和iBatis/MyBatis之间选择了。各有优缺点，你选择哪一个都没有错误。

2. 逻辑层

   这回说到企业应用的“核心”了，俺们做企业应用的，从几十年（至少20年）前就是靠这个起家的——业务逻辑。“企业应用”为啥高大上？高大上在哪儿了？就在这儿：业务逻辑！

   有人会问了，你之前不是说“没有啥算法可言”吗？是的，算法是没啥，但是业务逻辑不等于算法，比如俺们的排序可能就是个冒泡，但是为啥要排序、什么时候排序、按什么排序这才是业务逻辑要决定的。

   这方面，虽然不用太考虑高并发、大数据性能等互联网应用的家常便饭，但是纯业务方面的逻辑复杂度还是要比互联网应用高的。还记得那个比较12306和淘宝业务复杂度的帖子吗？从业务逻辑上说12306比淘宝复杂至少一个数量级。就算是普通的中小企业应用，同样都是卖东西，合同、订单、结算等方方面面都会比淘宝要复杂的，当然这里是业务逻辑间的比较。（不考虑大数据量方面）

   但是，并不意味着企业应用的业务逻辑处理代码就可以胡写一气，你有多少项目是在内部测试时呱呱叫的，到了生产环境下就趴窝了的？性能问题不是互联网应用独有的，这方面企业应用也同样重要。跟没有一样的索引，没有过大脑的SQL，1+N的SQL，嵌套的循环，IO操作，甚至String类型的频繁写操作可能都会成为系统上线后的噩梦。因此几乎每个团队都会或多或少的开发规约，但是哪个Team能把它从头到尾都严格执行那本身就是一件不可能完成的任务。

   # （开发过程中）定期与DBA一起重新审视Index
   # 禁止在循环中执行SQL语句
   # 循环嵌套不能超过2层
   # 禁止在本需要distinct的时候使用distinct（擦这句话是人说的吗？）
   # 多IO操作，比如循环里面写文件，应该考虑使用多线程
   # 超过3次拼接字符串，就必须使用StringBuffer(StringBuilder)
   # 还有很多，其实也算太多。。。

   拜托比起互联网应用的小伙伴们（谁说还有前台攻城狮来着？）你做企业应用的已经幸福太多太多了，这点小小的规则是最起码的底线了。

   学好OO，善用OO是设计业务逻辑层最起码的入行要求。时刻想着解耦，时刻想着抽象，OO那几大原则（有人说4个，有人说5个，6个...）时刻不能忘。用Spring就不要放过它的AOP。提到Spring，我还有一个忠告：“你作为一个架构设计者，能用配置解决的问题，就不要让开发人员通过注解实现。”

   推荐两本书吧：《Effective Java》《设计模式之禅》

3. 表现层

   做企业应用的人，最不屑的就是前台技术了，那都不是事儿。不论C/S还是B/S结构，一个好的GUI都是一个好的系统的必要条件。你可以试试棒约翰的网上下单系统或者光大永明人寿保险的客户查询系统（如果你是他们的客户的话），你就知道一个垃圾的GUI是多么让人抓狂了。在这一点上C/S的客户端也逃不掉，尤其是客户群体特殊的时候，回想一下医院刚刚推行系统的岁月，你去看病的时候，医生尤其是年纪大的医生是如何抓狂的。

   企业应用和互联网应用的GUI有很大的不同，前者要的是富客户端，类似于C/S WinForm的用户体验，而后者追求的是炫丽、方便、高效，前者以用户吐槽量为衡量标准，后者以订单转化率为衡量标准。相比之下企业应用有可以松一口气了，用户再怎么吐槽也得硬着头皮用，因为这是他/她的工作，而互联网则是用户完全自主权，你不够好我就换别家。但是，这并不是说企业应用就可以死猪不怕开水烫了，吐槽的太多了，万一人家老板决定更换供应商了，你再哭也来不及了。

   好吧，我抛弃那个上古时期的C/S就不说了，下面只说B/S结构下的表现层。我曾经在Flex(Flash) / WinForm / Web + AJAX 之间徘徊游荡过一阵子。

   2008年前后，那时候Adobe在中国正如火如荼的推广Flex。2009年我还去参加了一个Adobe在北京组织的沙龙，当时发布了Flex Builder 4，可能是鉴于Flex的名声远远不及自家的Flash，所以从4.0开始正式更名为Flash Builder。但是，也正是从这时候起，我渐渐的远离了Flex。要说原因吗，我想大概还是当初喜欢上Flex的哪些理由：BlazeDS已经为Flex与Java的协同作战铺平了的道路，RemotingService的使用方法简单到几乎是傻瓜式的。加之AS3带来的 绑定、事件触发器、异步 等“新”特性，“代码洁癖”驱使下的MXML与AS3完全解耦的MVC 等等。这些是Flex的“优点”，但很快我认识到这也是它的“缺点”，因为企业开发不是个人英雄主意，必须满足团队绝大部分成员的低门槛要求，这些特性显然不够简单，也至于无法迅速大众化普吉。

   还有一个很大的原因是，即使Flex非常炫酷，但是其操作性还是比不上传统的C/S窗体。那段时间在网上瞎转，看到了Hessian于是看到了除了低效的WebService以外，另外的沟通Java和C#的希望，C#的前端确实写起来比Flex的效率高，用户体验感也更好。（可以参看另外一篇http://tonylian.iteye.com/blog/399805）

   但是由于更新发布（即使是那时候微软推的One Client也不够方便）、用户对B/S的感官认识等方面的原因，加之各种优秀的js框架的不断涌现，我想B/S的前端还是回到Web页面的轨道上来吧。

   于是JAJX的One page app就成为企业应用最适合的Web前端载体。与互联网应用不同，企业应用多是表格+表单式的界面，多窗口、模态窗口等类似于传统C/S的界面，或者你可以把它想象成一个网站的后台管理员设置界面，当然会更加复杂。甚至很多B/S的企业应用，其实就是把原来C/S版的系统用B/S结构“复刻”一下，这个“复刻”尤其体现在GUI界面上。（其实除界面以为，可以复刻的还有业务逻辑，而实现方式等则要完全重新来过）

   Flex也好，WinForm也罢，它们在表现层似乎只是打酱油的角色，我们的主要精力还是应该放在Web上。今年来逐渐流行的移动设备，传导到企业应用自然也是慢半拍的，不，不是半拍，而是一拍甚至两拍。Android和iOS的表现层还没有大行其道，就大有被Web App所取代的趋势了，现在手机、平板上的Web App在强大的HTML5的支持下，驱动个摄像头已经不再是天方夜谭，拍照、扫描也可以很容易地嵌入到Web App中。（当然不要忘记在工业级的手持终端上WinCE还依旧是主力军，WinForm还有一席之地，但也在被Android逐步蚕食）

   回到主题上来，Web端的表现层，必须做到：单页面异步请求访问、动态加载数据、MDI多窗口、分辨率自适应、类似C/S程序的菜单、树状导航菜单。简单的数据请求方式、自动的错误提示、各种功能丰富的控件，尤其是Grid控件，要能编辑、列可拖动、可排序、可翻页、可冻结、可导出、行可移动、行可复制，甚至合计、分组、过滤等等。文本框和下拉框也比传统的Web控件要升级，自动联想、自动过滤、显示名称而实际获取代码等等。总之，要想给项目组提供一个简单易用的表现层平台，那么微软能做到的，几乎我们也要做到，微软没有做到的，我们也要做到。听起来是不是很恐怖？把基于Html、DOM的Web页面，变为基于控件和事件的窗体代码，我们再也不是用Html和CSS去“画”页面，而是用js去“写”页面。这看起来难度大增，但是对于程序员来说却是喜闻乐见的。

   浏览器的兼容性也不得不提，前端工程师最痛快的就是与多种浏览器奋战，再加上移动设备上的多种分辨率那简直是噩梦。还好当历史的车轮来到2015年的时候，很多浏览器无关性的js平台早已扑面而来了，前端工程师们迎来了前所未有的幸福。但是，浏览器兼容性并不是再也不存在了，我们还是要非常注意。特别是当你准备放弃那些“老掉牙”的IE6/7/8的时候，掂量一下你的“企业用户”的感受，那些“不差钱”的“大企业”是不是有钱更新到正版的Win7，或者他们是不是还有几个更加老掉牙的企业应用要求IE6或IE8 Only？

4. 三大层之间是什么

   程序员只需要知道三大层，就可以了，他们会看到数据在三层之间来回的传递。然而作为架构师你必须还要知道三层之间都发生了什么，都有什么。三层的背后又还有什么？

   数据传输：协议、数据加密、通道加密、序列化/反序列化、数据压缩
   服务安全：拦截器、过滤器、认证校验、访问控制、安全日志
   表现层附属：报表打印、图形化展示、文件上传/下载
   服务层附属：容器、系统日志、在线人数控制、负载均衡、Session同步、消息、外部接口
   持久层附属：连接池管理（优化）、缓冲区管理（优化）
   批处理： 进程控制、并发控制、批处理控制、消息机制

   除此之外，作为一个企业应用框架还需要提供以下常用服务：配置文件读取、邮件发送、用户管理、密码加密（要能够防暴库哦）、用户间消息、业务日志、工作流引擎甚至全文检索引擎。

   这些内容每一项都够写一篇小论文的，再加上单元测试助手、发布助手，要完成一个企业应用框架并非易事。

   当然还有一个非常重要的东西——代码生成工具。B/S系统最让人头疼的可能就是铺天盖地的配置文件了，数量庞大、内容苦涩。代码生成工具不仅仅是生成代码，同时必须也能够生成99%的配置文件。一是把程序员尽可能从庞杂的代码中解放出来，二是因为要生成代码而“逼着”程序员写出完整、正确的设计文档（是那种把Excel发挥到淋漓尽致的表格式设计书，不是Word文档哦）

   总之，一个企业应用框架就是让一个项目从开发、设计开始的第一天起，就能够“只关系
业务需求，除此之外的一切技术问题均不需要考虑”。业务上有任何一个需求，都可以在《框架指南》中找到答案。除了从未使用过这个框架的成员的学习曲线之外，整个项目的开发进度不受到技术方面的任何影响，从第一天开始就是100%的效率。对比以往没有成熟框架的大型项目，那时候在项目过程中“逢山开路、遇水搭桥”，当项目进行到收尾阶段时才能说开发效率已经开足了马力，我们一开始就已经开足了马力。

   要想达到这样的“境界”并非易事，架构师必须站在前人（巨人）的肩膀上，既要整合已有的框架、也要创新出适合企业应用的特性、更要避免重新发明轮子。本文中所提及的各个关键字，每一个都够写一篇小论文的了（这句话前文已经说过了），它们每一个几乎都已经有了成熟的解决方案，架构师需要的是从众多方案中甄选出最适合企业应用场景的，最适合和其它方案整合的那一个，并且把它们整合好，当然也不排除在某系领域需要自己动手。

   时间仓促，在农历马年的岁末，就先写到这儿吧，算是个初版，如果有时间，羊年后再做整理。