“项目产品平台”我的编程人生

 

         如果您认为这篇文章主要讲“我”的人生经历，那就错了，我很少写感慨之类的文章。没有哗众取宠的意思，只是想说我是如何走上架构这条路的，以及架构的心得，并讲述我目前正在架构的内容。也为以后的文章做一个铺垫。

         主要讲下面的几件事情：

n  项目à产品à平台的经过

n  架构心得

n  现在的架构内容

n  架构的完美性

项目à产品à平台的经过

像很多人一样做过很多的项目，不知别人怎么样想，我的感觉是做项目真的很累。为了赶时间，代码倒是写了不少，但总感觉形同散沙，不是一个精巧的有机整体，偶尔会有一些灵机一动，但望着不可预期的改造成本而渐渐变得麻木。沉淀下来的是编程的经验和对客户的需求的把握上。然而不管怎么样或多或少的有了些可以重用的东西，也有一些小范围内的抽象能力。

         从项目到产品的过渡不是我刻意布的局，公司项目的产品化过程才是直接的原因。项目成熟后，当有新的需要与以前的项目差不多时，很自然地把项目改造放到了首选位置。然而重点不是在改造本身，而是项目的定制上。把一些变化的地方从整体中分离出来做活，为以后处理类似的项目打下基础。久而久之产品也就形成了。此时变化点的分析及分离能力得到可观的提高。

         好的公司在不断的成长，从单一产品发展到覆盖某一领域的全套产品。这时，不同产品之间的交互及操作的一致性成为最重要的需求。公司为了进一步缩减开发成本，提高开发效率，应用集成便提到了日程上来。必须从一个新的高度重新开始架构应用，以找出不同应用之间的共同点和变化点，这需要更高层次的抽象。代码级别的重用已经不能解决这个层次的问题了。

         现在大家都在讨论SOA，这的确是一个好东西，也许SOA的概念比较大，而我只是在不同的应用之间共享一些数据和服务。如统一的用户系统，授权系统等。我不知道这是不是SOA，但精神是达到了，“面向服务”。这时重用的已经不是代码了，而是服务。还好现在这个时代已经为我们做好了这方面的技术标准即Web Services技术，（题外话：其实我个人更喜欢WCF成为行业的标准，不是跟微软的屁股，确实他做的很好，把服务和通讯方式分离开来是一个质的飞跃。）我们可以很方便地构建我们的服务。这些基础的服务汇聚起来，应用平台的概念便产生了。

         上面写的是我个人的真实经历，肚子里没东西，写的不多，但整个过程是12年，每个阶段对我个人的成长有着不同的意义。想一想中间有很多浪费，当然不是说颓废，只是走了很多的弯路。期间的意义在于，如果您一开始也打算走架构这一条道，希望我的文章能给您一些启示。

架构心得

         如何能够成为一个好的架构人员，我不敢妄言，只说一下我自己的一些见解。想到哪说那，感觉层次不是很整齐，还望见谅。

l  经验，来源于两方面的经验：

Ø  编程经验：代码一直写下去，去理解面向对象技术及设计模式如何大刀阔斧的改造我们的代码，只要努力，时间会给我们最好的印证。

Ø  项目经验：了解哪些是重要的那些是次要的，用好80-20法则，做好多次迭代的准备。把握好抽象的粒度和深度。

l  设计模式：

一定要看，不一定要记住。为了应用设计模式而去设计是错误的。从现有的具体情况出发，依据想要达到的目的去套用才是应用设计模式的好方法。

l  Web Services服务（简称WS），WS本身并不难，难在给WS瘦身！我个人不建议直接将WS公开出来给各种不同的应用使用，否则我们会有很多的麻烦：

Ø  我们无法了解应用的实现的好坏，可能会去公开一些本可以不用公开的一些方法。

Ø  安全方面的问题会使我们很头痛。

Ø  不能干预网络传输的优化。

三层及多层的应用已经成为主流，要想给我们的WS瘦身，就需要多一层自己实现的客户端，以取代各种应用对WS的直接调用。这样上面的问题都会在自己实现的客户端里得到很好的解决，而且简化了应用调用接口的设计，并部分地封装了应用的业务逻辑，即对应用本身也瘦身了。另一个重要的效果是，不同应用的操作一致性至少在平台基础操作上得到了一致。

现在的架构内容

         平台的建设在一个大型的应用环境中是非常关键的，其基础功能提供了的质量及数量直接影响多种应用的集成效果。最重要的是体现在客户使用的方便性及部署，维护的简易性上。

依据具体的实际情况，平台应涵盖的内容是不同的，这里讲的架构内容具有一定的通用性，但不一定就适合你的需要！这里只是概要说明，详细说明留意后继的文章。

l  用户系统：行业里早已经有passport之类的东西，然而总是感觉功能不健全，部署复杂，扩展困难。这里需要提供一个可伸缩的，分级管理的用户系统。包括用户库，用户组两个子系统。用户组的存储可以依据不同的应用有各独立的存储空间（数据表）。

l  授权系统：.Net里也有类似的东西，还是不够用。在这里进行了高度的抽象，一切授权使用视作对某一特定资源的授权，包括高级别的管理权限的分配。另外一点是存储上的分布，每一种资源都有各自的授权信息表，这种资源可以是存储在物理上分布的多个物理库内。

l  许可证验证系统：这个意思简单不多说，唯一要说的是许可证为每个登录成功的人发放，并作为票据访问WS，WS依据该票据对客户端进行身份验证。

l  服务验证系统：为了保护WS，与许可证验证系统一起使用。

l  服务地址冗余系统：简化客户端对WS访问的配制过程，并提高系统的稳健性。

l  数据库冗余系统：WS和数据库之间是分离的，通过该系统WS可访问到正确的数据库，同时提高系统的稳健性。

l  工作流系统：这个目前可能有些局限性，只适合于审批流程。依赖于平台的用户系统及容器系统（一个通用设计的数据表，可以管理类似目录树，用户组，各种分类信息的平台基础功能）。技术细节甚多，是基于WF实现的，有意请参见我的博客http://llxxbb.cnblogs.com。旨在提供一个易用客户端，客户可图形化设计流程的工作流平台。

l  数据迁移：一个大型的数据库应用系统在上线后，随着时间的推移，数据库容量会是一个不大不小的问题。应用的数据库逻辑只有应用才可以清楚的描述，要做一个与应用无关的数据迁移系统必须要有高度的可配置性，才可能真正的通用起来。这可以是一个独立的工具，也可以进行封装以纳入平台的数据库管理。

l  ……

架构的完美性

         追求完美是人的优秀品质，我本人也是一个完美主义者，但完美会破坏80-20法则。有一句话我不知说的对不对：真正的完美在于她80%的完美和20%的遗憾。过分的通用会不会发展成一种新的“文字”！我的架构不是完美的，还有很多的东西需要做。但对我个人而言，她又是完美的，因为她确实能给应用带来很多的实惠。