#
在工作流管理系统中，通常是先给业务流程建模，利用流程设计器，将业务的办理过程用流程支持的节点方式表示出来。
业务建模之后，再确定每个节点上办理的业务，办理业务的过程，通常是以填写完业务表单的方式来完成的。所以需要分析每个节点上填写的表单内容，根据 表单内容建立业务表，表字段等。再将字段绑定到表单中录入控件上，将表单录入的数据保存到数据库中，这样业务表单模块就完成了。
业务表单完成之后，再挂接到流程节点上。
另外可能需要再次完善一下流程节点的一些属性，如增加每个节点的指定办理人。
设置取业务表中的一些关键值用于流程中，如取报销单中的报销金额，请假单的请假天数，用于流程上下文中做条件使用。
最后，在业务表中，需要增加一个流程实例id字段，用于和业务流程关联。在启动业务流程的时候，需要将获得的流程实例id写入这个字段中，使得业务记录能和流程实例关联上。
通过上面这些步骤，就建立好了业务流程了，可以启动流程实例，办理业务了。业务的流转就按照流程建模中定义好的顺序办理，不需要再在业务表 中增加状态字段来控制业务的流转了。业务的办理过程变得有迹可循了，每个流程实例均可以列出运行的轨迹图，或者列表出运行的轨迹。每个节点上办理的业务也 能通过查询业务表单再次展现。
上面我们说过，业务表是存储办理业务数据的数据库表，一般来说，一个业务表只用于一种业务流程中，存储同一类型的业务数据。当流程运行结束的时候， 这些业务数据就被封存，不能在流程的节点中再次被编辑和修改。(除非直接开库修改数据，或者另外做一些模块，直接修改业务数据)
但是，这些封存的业务数据，有可能会被再次启用投入到另外一个业务流程中去使用，这种需求可能是需求肯定是有应用场景的，不管是分段的处理过程还是后期又做的一些业务补充等，都有可能发生。
如果一个业务表，需要再次用于另外一个业务流程当中，则我们只需要给业务表，再增加一个流程实例id字段，就可以了，再次新启动的业务流程获得的流 程实例id就写入这个新的流程实例id字段。和以前的那个流程实例id不相关了。只是如果是编辑同一条业务记录的话，就可能把上次的数据给修改了。这样理 论上是可以支持n个业务流程。
总结一下，一个业务表用于一个业务流程中，用一个流程实例id字段和流程关联，用于另外一个业务流程中，则再建一个流程实例id字段和流程实例关联。
一个业务流程可能会涉及到多张业务表，一张业务表也可能涉及到多个业务流程。
现在各种MVC框架很多，各框架的优缺点网络上也有很多的参考文章，但介绍各框架性能方面差别的文章却不多，本人在项目开发中，感觉到采用了struts2框架的项目访问速度，明显不如原来采用了struts1框架的项目快，带着这些疑惑，我对各类MVC框架的做了一个简单的性能分析比较，其结果应该说是基本符合预期的，可供大家参考。
测试环境：
CPU：酷睿2 T5750，
内存：DDR2-667 2G，
Web容器：Tomcat6.0，最大线程数设置为1000，
操作系统：WinXP-sp3
测试步骤：
搭建6个Web工程，如下：
1.纯JSP:不包含任何MVC框架，只有一个测试用的JSP页面。
2.struts1：包含一个Action，不做任何逻辑处理，直接转发到一个JSP页面
3.struts2 JSP：不包含Action，只包含测试JSP页面，直接访问该页面。
4.struts2 单例Action：采用Spring来管理Struts2的Action实例，并配置成单例模式。
5.struts2 多例Action：采用Spring来管理Struts2的Action实例，并配置成单例模式。
6.SpringMVC3：采用Spring来管理Controller实例，包含一个Controller，不做逻辑处理，收到请求后，直接返回到一个JSP页面。
测试结果：
|
测试工程
|
请求数
|
并发数
|
总时间(s)
|
总时间(s)
|
总时间(s)
|
平均值(s)
|
Requests Per Second(每秒处理请求数)
|
|
JSP
|
2000
|
200
|
5.55
|
3.59
|
4.11
|
4.42
|
452.83
|
|
struts1
|
2000
|
200
|
6.77
|
3.83
|
7.00
|
5.86
|
341.03
|
|
struts2 JSP
|
2000
|
200
|
25.20
|
26.30
|
24.11
|
25.20
|
79.35
|
|
struts2 单例Action
|
2000
|
200
|
28.36
|
27.59
|
27.69
|
27.88
|
71.74
|
|
struts2 多例Action
|
2000
|
200
|
31.31
|
31.97
|
39.56
|
34.28
|
58.34
|
|
SpringMVC3
|
2000
|
200
|
7.16
|
7.50
|
4.27
|
6.31
|
317.09
|
说明：
以上测试虽不是非常的精确，但基本能说明一定的问题。每个JSP页面和Action都不包含任何的业务逻辑代码，只是请求转发。每轮测试取三次总时间的平均值。所有工程的测试均全部完成并正常处理请求，没有请求拒绝情况发生。
结论：
-
纯JSP的性能应该最高，这不难理解，JSP被编译成Servlet后，没有任何多余的功能，收到请求后直接处理。（这也验证一句经典的话：越原始效率就越高。）
-
struts1的性能是仅次于纯JSP的，由于struts1采用单例Action模式，且本身的封装相比struts2应该说简单很多，虽然开发效率不如struts2，但已经过多年的实践考验，性能稳定高效。
-
相比来说struts2的性能就比较差了，这不难理解，struts2之所以开发方便，是由于采用值栈、OGNL表达式、拦截器等技术对请求参数的映射和返回结果进行了处理，另外还采用大量的标签库等，这些都无疑增加了处理的时间。因此降低了效率。在我们实际的项目中，我测试本地工程访问每秒处理请求数只能达到35左右，应该说还有不少可优化的空间。
-
很多人认为struts2性能差是因为它的多例Action模式导致的，但我们采用spring管理struts2的Action，并设置按单例方式生成Action实例后，发现其性能有所提高，但并不是很明显。由此可见，多例Action模式并不是struts2性能瓶颈所在。另外，我们在struts2中采用JSP方式访问，发现其性能依旧和没有采用任何MVC框架的纯JSP之间存在好几倍的差距，这又从另一个侧面证实了我们刚才得出结论，struts2性能的瓶颈不在于它的多例Action模式。
-
SpringMVC3的性能略逊于struts1，但基本是同级别的，这让人眼前一亮，springMVC有着不比struts2差的开发效率和解耦度，但性能却是struts2的好几倍，这让我们灰常振奋，SpringMVC无疑又是项目开发的一个好的选择。
Hadoop最近很火，到处都能看到，查了一下资料大概先了解一下其运行原理。
google在05年公开了Map/Reduce论文，MapReduce在处理巨量数据方面有明显优势。
google公司一个技术大牛jefffery Dean提出的这个算法，随后很多小牛纷纷实现了Mapreduce,Hadoop是它的java实现，MapReduce概念直接推动了云计算概念的火爆。
没有优秀算法云是没法搞的。
这篇文章对Map/Reduce原理讲的很清楚。
http://www.chinacloud.cn/download/Tech/MapReduceOverview.pdf
这个是Apache关系Hadoop的文档，安装、开发示例都有。
http://hadoop.apache.org/common/docs/r0.19.2/cn/mapred_tutorial.html
官方WIKI
http://wiki.apache.org/hadoop/Running_Hadoop_On_OS_X_10.5_64-bit_%28Single-Node_Cluster%29
什么是云计算？
- 网格计算（Grid Computing）
- 分布式计算（Grid Computing）
- 并行计算（Parallel Computing）
- 效用计算（Utility Computing）
- 网络存储（Network Storage Technologies）
- 虚拟化（Virtualization）
- 负载均衡（Load Balance）
表现方式
- 基础架构即服务（IaaS）：Amazon Simple Storage Service，通过Webservice API向外界提供存储服务，数据存到分布式的各个地方
- 平台即服务（PaaS）：Google App Engine，开发平台，写一个JAVA程序部署到上面；Amazon Elastic Compute Clouding
- 软件即服务（SaaS）：Salesforce.com，提供在线的CRM，根据需要买帐号，服务等，企业无须开发系统；Google App，提供一整套的办公系统
以上所介绍的可以称为公有云。
云计算给我们带来了什么
- 小企业：通过公有云降低成本，按需采购IT资源，以小拨大
- 中大企业：通过私有云，提供全新的IT交付方式，高效可扩展的系统
- 开发者：全新的开发模式，需要做一个转换，即熟悉大规模并行运算
关键技术
- 分布式计算模型：MapReduce
- 分布式文件系统：HDFS
- 分布式数据库系统：HIVE
云计算对企业的价值
高度可用性，高度可扩展性
案例
- 金融数据收集分析系统：以廉价的IT设备收集少量金融数据，前端有各种模块收集数据-->云计算模式进行数据处理
-->保存到传统数据库-->用户展现
- IT知识库系统：前端数据取模-->云计算模式进行数据处理-->用户查询-->查询API
JAVA平台对云计算的支持
著名的开源实现：Hadoop
项目组成
- Pig
- Chukwa
- Hive
- MapReduce
- HDFS
- Zookeeper
- Core（核心部份，任务分配，调度）
- Avro（处理序列号）
MapReduce模型
- 源数据（Map）-->中间数据（Reduce）-->结果数据
- 处理流程：客房端提交任务-->Master Node决定如何折分任务-->分到各节点
- 实现：先启动Hadoop系统-->编写客户端程序-->使用Hadoop运行客户端程序
最近看Jboss in action，里面提到Jboss的hot deploy功能，今天动手试了一下了一下，发现确实很好用。
首先使用eclipse的Automaticlly publish when resources change 功能 ，设置一个较短的时间，比如一秒，那么在编辑保存之后，eclipse会自动发布更新到jboss部署目录。
在jboss中，可以使用Jmx Console，deploy，undeploy和redeploy。
例如：C:\Jboss\bin\twiddle invoke "jboss.system:service=MainDeployer" redeploy file://C:\Jboss\server\default\deploy\jbosstest.ear 。即完成对jbosstest.ear的重新部署。
在eclipse中可以把jmx命令行客户端twiddle配置为外部工具。
这样，每次修改后，点击
即可重新部署应用程序。
所谓的热部署（热发布）（下面称为“热部署”），就是说，在web工程发布之后，不可避免的，会遇到修改BUG的问题。现在的热部署就是为了解决这个问题，其功能就是说：在不停止web服务的同时，对jsp和java类进行修改，修改后的效果同时还能够在页面上显示出来。节省了调试时间，提高了效率。不过，修改配置文件是个例外，如果对配置文件做修改，一定要重启web服务。
常用的web服务器一般为tomcat和jboss，现一一做介绍。
1.tomcat热部署
在tomcat中支持热部署有两种方式（在原理上来说，这两种方式是一致的，只是放的位置不同）
a)在catalina_base\conf\catalina\localhost\中依照manager.xml定义一个xml文件，比如我的项目称作sodoperation，我们就可以写一个sodoperation.xml，内容如下：
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
其中，path指的是你在tomcat中的项目名称，就像manager一样，docBase是指你的项目所在的web目录。一直到欢迎页面为止（也就是web-inf的前一个目录）。但是一般来说，这个目录中最好不要有中文，如果有的话，可以在文件开始加入
<?xml version='1.0" encoding='utf-8' ?>来试一下，即整个文件变为：
<?xml version='1.0" encoding='utf-8' ?>
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
这样就可以了，如果用这种广告，同时使用myeclipse的部署的话，轻易不要remove，这样会使文件都会被删掉，不能持久。所以，建议使用第二种方法。
b)第二种方法和第一种方法在原理上是一致的，其区别就是位置的不同，这次在catalina_base\conf下的server.xml，在文件末加入：
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
解释和上面一样，这种方法在启动tomcat后，会在catalina_base\conf\catalina\localhost\中加入一个与第一种方法的文件。这样保证，只要对server.xml不做修改，你可以随便对新生成的文件删除，对热部署没有任何问题
2.jboss热部署
在jboss中做热部署也有两种方法，因为jobss集成了tomcat，也可以说这两种方法是在jobss上的一个修改。
a)修改
/opt/jboss4.3/jboss-as/server/node1/deploy/jboss-web.deployer/context.xml
<Context cookies="true" crossContext="true" antiResourceLocking="true" antiJARLocking="true">
<Manager pathname=""/>
<InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener>
</Context>
加上
antiResourceLocking="true" antiJARLocking="true",重启jboss,再用myeclipse Redeploy project的时候就不需要重启,部署完了直接开浏览器预览啦
什么才是软件架构呢？这是一个让人费神的事情，其实呢我觉得“软件架构”至少应该是一个动词，而不是一个专有名词。那么什么才是架构呢？按照我个人的理解，架构这玩意简约不简单。“架构”的过程是一个把抽象转化为具体，其中的美妙不会低于设计师创造艾菲尔铁塔那般的感受。架构的过程会让你变得偏执、疯狂。至少在短时期内会为之寝食难安。那时时候你的世界之后架构二字了。有点长，希望耐心看完～～～ 哈哈！
（PS：尽管架构是与编程语言无关的事情，目前采用Java语言作为例子）
好了，很多人读到这里会怀疑，难道J2EE业界流行的那些SSH、SSI 不是架构吗？我的回答是“NO”，如果硬要如架构沾边的话，那也充其量是一个架构最最低级的一种。在现在的我看来，那些只不过是一些开源框架的简单集成，毫无技术含量可言，对于架构者本人而言，那就是通过固化的配置把这些开源框架进行一定程度的粘合，使其能互相配合完成工作。当然不是否认这个配置的过程，但是这个过程是机械化的学习，丝毫看不到自己的想法，这时的想法都被固化的配置所代替。想当年 偶也是这样子走过来的，所以说呢，现在的我不敢谈论架构的内涵，仅仅是表达出我对架构的一些想法。文以记之。
好了，经过SSH简单的粘合之后，感觉自己很伟大，而且看是跃跃欲试的样子，拿来做项目，这是必经的一部，从程序员到架构是一个设想与实践相结合的一个过程。你自己架构的东西必须通过项目的实践，才能了解是否有改进的余地。我是比较幸运的，一直以来很多项目都是我架构之后在实践呢，在这里感谢那些曾经呆过的公司。是他们给的平台才让我有今天坐在这里写文章的冲动。很多人在使用简单粘合的SSH框架去架构你的项目，你会发现那玩意不适合做项目，太原始了，仿佛回到了石器时代，当然当时你的水平估计也就是才进化到铁器时代吧。
第二阶段了，开始尝试修改SSH搭建的框架，新在而言还是用“框架”来形容比较的贴切一点。通过一轮或者几轮的项目实施，你会发现其实SSH等这些也不是很完美，至少还有很多地方可以改进，这时你已经不再满足于SSH的简单那粘合了，开始尝试去修改加工SSH的粘合。增加一些与SSH直接交互的隔离层代码，这样一来自己项目的代码干净了很多，SSH从入侵式到非入侵式（不可能100%），这已经是一个了不起的飞跃了。你发挥了作为人主观能动性的权利，现在你收获了。那改造的SSH继续项目到项目中去实践，也许改造后的架构在当时的你看来已经很完美了。勇者无惧，Going，开始第二阶段的试水，感觉很好吧，现在的你也许长大一点了，不再从单一的技术去看待项目了，开始考虑项目的开发计划了，有了后则一层的考虑说明你是一位勤奋好学的好孩子，已经不再是单纯的Coder了，面对计划，在看看自己的架构的“框架”，时间紧迫啊。用这玩意尽管目前代码尤雅了很多，但是对于项目小组成员的开发进度还是帮助不大，大家需要学习的东西太多了，Spring、Struts、Hibernate ....... 这对于经验不是很丰富的程序员而言，简直就是噩梦。考虑到这一点，你就开始进入第三阶段的进化了
第三阶段，开始思考屏蔽各种框架集成带来的复杂性，让不懂SSH框架的人也可以快速上手使用，为了达到这一点，又开始废寝忘食的框架重构，增加更多隔离层的代码。这时的框架有点架构的味道了，重构之后的你会洋洋得意，认为这是很完美的了，又去屁颠的拿去项目实战了，这时发现你隔离之后的反而适得其反，百思不得其解啊？什么情况呢？因为你对粘合的框架内核机制不了解，这时的你要虚心学习那些开源框架了，必须是源码级别的阅读，了解他们的内核机制，才能写出更好的隔离层，面对大量的源码，必须有个入口吧，下面我简单吧Spring的入口告诉大家：首先是Spring的Ioc容器，这是核心，主要是看init bean以及loadbean的这点内容是精髓，Aop的话比较深入了，简单一点就是采用动态代理方式实现AOP，在高级的就是采用CgLib的动态代码切入实现。学好这两个之后。在学习Spring MVC 了，这是一个难点，你要吧Mvc的解析流程整理好了，在从每一个环节思考架构为和要多一个这样的环节。（Struts1 太简单了，Struts2太复杂了）。言归正传了，经历一轮源码的洗礼，你脱胎换骨了，SSH对你而言 使用起来游刃有余了。你再也不用为框架不熟悉费力了，这是的你充满了自信，短期内不再关注学习框架了，更多的时间分配给了架构。这时应该进入第四阶段了吧
第四阶段，开始用全新的眼光以及思维去粘合SSH，不错，很多以前的使用不当现在都让你轻易的化解，而且开始考虑使用SSH特有的一些优势去美化的你的架构。现在的你开始考虑的不是开始了，而是如何保证代码的质量问题了，如何保证呢？好吧，找领导申请资源测试吧，对不起，测试团队是很昂贵的，公司很少会配备测试团队的，自测？小弟们才不会如此上心呢？未雨绸缪吧。架构时候为何不架构一套基于SSH的单元测试框架进来呢，好处呢可以脱离容器去测试功能，基于框架的单元测试进入了你的思考范围。等从思考到完全融入架构的时候，你有进入一个新的阶段了。编写测试架构就是为了提高工作效率，目前面向Web的开发，很多测试都需要依赖容器，每次启动容器调试是何等的低效啊。好了集成了自己的测试框架，小弟们高兴了。也会对你刮目相看，至少编写单元测试是一个程序员的义务，保证自己的代码的稳定性，现在你轻松了，每天吧小弟的成果用写的单元测试运行一次。没问题了，不错。下班。
第五阶段，也许这一阶段你的架构开始稳定，很长一段时间都会固化不变，也许到达了一个瓶颈了。单位来了狠多项目，每次你都构建一个基础成，1次 2次 。。。N次，O-MyGod，你开始讨厌这种重复的的劳作了，得，这是你的责任，你是公司的技术一把手，这些肯定有你来做。这是你开始考虑吧基础层与业务层开始解耦。解耦出来的东东作为单独的一个项目存放，自己手动维护，以及版本控制。新建的项目都依赖你的基础项目在做业务开发，现在感觉好多了，不用在为项目每次都搭建了。看着别人在忙，你在一边抽烟偷着乐吧。新在的你体会到一丝分离的快感。这不是就是所谓的程序的解耦吗？这不过你解耦的比较彻底了，从功能和物理上都实现了解耦。恩体会到设计模式的优美了，这是你也会才会发自内心的去迷恋设计模式。这些设计模式是前辈们精华的抽象，不同的模式用于解决各种现实的业务建模。学会是一回事，灵活掌握是另外一回事。关于设计模式，是必经的过程。不仅仅是学会，关键是灵活使用。在合适的场景下选用合适的模式，才是正解。
第六阶段了，通过之前的积累，你已经开始迈出走向架构的第一步了，之前都是为这一步的积累。好比是砍柴，之前都是磨刀了，现在才开始踏上砍柴的路途，哼着儿歌、一路进发。现在刀不是问题了，估计之前的砍柴都是刀不好，注意力都在刀上了，现在刀是没问题了，开始转移到观察柴了，什么柴比较好，砍哪里可以一刀成功，这些多是经验。映射到软件项目就是，开始关于业务建模，不同行业的业务都有其自身的特性，如何针对这些特有的业务特性去架构框架呢，在之前的隔离层上在封装一层业务支撑体系，这个体系可以良好的为业务系统提供强大的动力。通信、政府、金融、医疗、企业、税务、电商。。。。等等，每种行业有有其自身的业务特色，干活去吧，都发现架构的不足了，那就继续完善吧。coding～～～～～好了，针对业务的支撑层也开发完毕了。通过实践运行不错。。。。。 这时你的框架成了公司的某一业务线的开发平台了 。。。。如果继续留在公司，你也许会不断完善其业务建模的支撑体系。可惜，你可能换工作，换工作就意味这换行业。之前积累的业务体系完全行不通啊～～～悲剧了，没办法，从小弟开始做起吧，虚心学习业务基础 。。。。
第七阶段，跳槽太多也不是坏事，经历了几个不同的业务线，你敏锐的嗅觉开始体验到一些独立与业务之外的程序处理规则。如何能搭建一套快速满足不同业务建模的基础模型出来，说到底业务到了底层还是各种流程，只是每个流程节点处理的内容不同（不是工作流，但有其思想）。这时候，你考虑的问题已经不是业务建模了，而是业务之外的东东，这个时候你会忘记SSH这些所谓的框架，这些都是具体的形式体现，现在你需要的是高度的抽象，抽象业务之外，流程图是你研究的核心，因为任何程序其实都可以用流程图去表述，如何开发一套流程配置解析引擎呢，神码业务都是流程上的一个节点而已。只要业务流程化，按照我的配置写入，那么他就可以运行。见山不是山的境界吧哈哈～～～ 到了这一步了，感觉架构才是正的开始了。当然框架是抛不开的，现在面临的问题就是如何利用既有成熟的框架是完成你的这些构想，现在的框架开始考虑自己的分层了，内核层、安全层、缓冲层、ORM层、异常处理机制、国际化机制等等，是不是一项伟大的工程呢，也许Spring就是这样子走过来的。完成了这一阶段的修炼。那么你还不满足吗？恩的确有点就是说不出来，总是有点不满足。现在开始讨论更深层次的话题
第八阶段，架构是有了，你的项目规模也越来越大了，用这个玩意的人也越来越多了，现在考虑的是如何把你的框架能快速推广，市场是检验产品最好的标尺。是否具有可用性。是否能量产程序员（入门级），是否能保证代码的质量、是否能保证出现问题的快速定位，是否能够满足业务扩张的需求、是否满足性能的要求………………….. 咳咳～～一口气说完 太累了！！这些问题是现在需要考虑的问题了。现在架构的推广不仅仅是你的团队在用，也许其他团队也在用，可惜他们无法得到你的亲授，肿么办?开始文档化、标准化、提供实例Demo，这些够了吗？对了 还不够，100个程序员有100中独立风格的编程方式，那就意味这有100个风险的存在，你的架构如何屏蔽或者降低这些风险呢？答案呢？就是要用你的架构去诱导他们尽量编码风格一致。其好处不言而喻啊，统一的编码风格意味这每个程序员都是平等的，从项目角度考虑，那就是把人的风险降低了（包括离职风险）。带来的另外一个好处就是Review代码的快捷，统一风格的编码无需讲解 ……. 自己体会吧。说再多也是没用这个要亲自体会的。到了这一阶段感觉自己是什么？在雕琢一个艺术品？哈哈～～ 这个时候更加需要实践，去完善你的架构。因为现在你的架构是真正的架构吧。这个需要天时地利人和多方面的支撑。能达到这一步的程序员需要的不仅仅是自己的努力了，也需要公司的大环境……………….. 这就是为何什么程序员需要找适合自己发挥的平台。公司成了员工技术发展的桎梏。其结果就是让其平庸，或者释放去更宽广的空间。哇塞。好长久的文章啊。读者看到这里，需要休息休息了，找几张美女图片看看吧～～～也许我的文章让你费力了。现在OK了吗？架构可以了吧。恩 还是有差距的。
第九阶段，见山是山，再次回归项目中来，项目的目的是什么，盈利。这是最本质的东西。偏执也好、狂热也罢。这是一条基准，违背这一原则的任何架构都是失败的架构。盈利不是结果，而是项目每一步风险规避的积累。架构这是需要考虑的就是如何让架构能在每一阶段都能起到规避风险的功能呢？这是一个比较空洞的概念。但是这是必须考虑的，涉及到架构任何一个细微之处的调整。从项目开始到投产到维护。。。。这个过程，架构如何能保证每一阶段的风险规避呢。或者提供解决风险的更好的方法 ………………………..
上述为架构师修炼的过程，架构是具有中国特色的架构。不同于国外，一些老外闲的蛋疼去研究，我们都是苦逼的项目中提炼自己，利用8小时睡觉，8小时工作之外的时间去完成这一修炼，上面的文字也是本人的程序开发的成长历史，抛砖引玉吧～～希望能对开始“架构”你提供一些参考。最后浓缩几个字，算是文章的目的！
盈利、重构、坚持 。