最小化技术平台的构建(11.7)

做软件开发的往往都清楚，对于新开始一个软件项目或软件开发，特别是从零开始组建软件开发团队到开发完成并交付，最开始一个重要的工作就是要搭建一个最小化的基础开发框架，基础平台和公共组件能力，这个步骤完成了才是拆分相关的功能模块，然后安排不同的开发人员进行开发和集成。

能够完成这个基础支撑平台的搭建，并确定好标准的开发框架和模式，拆分好开发模块和组件，虽然说不一定能叫一个完整意义上的软件架构师，但是已经至少具备了开发组长的能力。一个公司如果从头开始做软件项目，那么最重要的就是要有能够完成上述工作的开发组长的角色。

一个软件团队开发完成一个软件项目，哪怕是很小的项目后，一定会有这种公共组件和开发框架的积累，那么在后面接手新的项目的时候很多内容就可以复用原来已有的内容。同时在新的软件开发过程中进一步对基础支撑平台进行功能完善，能力增强。

对于善于总结和复用的软件开发团队或架构师，你就会发现后续的新项目开发工作越来越简单，基本上对于标准的技术平台和共性能力你都不用考虑，而只需要考虑业务功能的实现即可。但是有时候也有糟糕的情况，就是一些架构师太痴迷于新技术，对于基础框架和架构总是不断的更换，只要有什么新的流行技术一出来就恨不得马上应用到项目里面去，只用最新的而不是用最合适的，这种思路也极大的增加了平台开发运维成本投入，同时也很难真正形成持续化的技术积累。

记得09年做项目的时候，项目团队也是基本每年就换一个框架，类似Ext，传统的jsp,html，Flex，Tapstry5等各种框架都应用了一个遍，最终才最近几年基本固定在JQuery框架上面进行了进一步的封装和固化。里面也走了大量的弯路，投入了大量的重复开发工作量，而这些本身是在前期最好规划和选型完全可以避免的。

其实对于最小化技术平台的搭建，在前面很多博客文章的里面我都有提到过，在这里再次进行说明。

如果项目是开发一个独立的单个系统项目

如果是构建单个业务系统的基础平台，那么相对来就简单了很多，但是实际上做起来细节的事情仍然是比较多，初步分析也应该包括如下几个方面的事情。

1. 初步的UI/UE界面风格要确定下来

2. 采用的开发框架要确定下来，具体是几层架构，数据层，前端展现等各自用什么技术都要定下来

3. 提供最基本的核心系统管理模块能力(用户，角色，授权，组织，菜单，数据字典等）

4. 基础的登录功能实现，并整理提供完整的Session对象值

5. 对于有流程需求的需要提供基础的流程引擎能力，不一定完整，但是具备间的流程审批和流转能力

6. 公共技术组件模块(提供一些类似公共函数，缓存处理，日志封装，异常封装，安全等基础能力)

实现上述内容后能够达到了一个效果就是，具体的业务需求可以划分为不同的业务功能模块，并将功能模块的开发安排给不同的开发人员去实现了，即基础底层能力已经具备，开发人员只需要实现功能并集成到整体框架里面来即可。

在这个过程中，有复用意识的架构师或开发组长一定要多做CodeReview工作，即通过Code Review来发现有哪些需要进一步抽象的公共组件和方法，并将其统一提供到公共的组件模块里面，以减少整体项目里面的各种重复代码，并提升代码的可维护性。

传统的软件开发团队做项目如何做？就是形成上面这个基础的开发框架和平台，然后再接到新项目后，将上面的这个集成平台和公共组件内容完整的拷贝一份出来（新拉一个分支），然后再来开发新的业务子系统。这个时候平台层还很难做到完整的黑盒级别的复用，但是基本可以实现新项目开发不需要再过多考虑这部分内容。

由于会全部拷贝出来，容易引发的问题就是在新的项目中对基础组件又进行修改，导致后续基础平台存在多个维护中的版本。因为这个原因，最好的方法仍然是对于基础组件平台最终成型后，最好的方式是提供类似Jar包引入的方式进行黑盒级别的复用。以确保基础平台的版本唯一性。

如果项目是开发多个子系统的大集成项目

在这种情况下，基础平台就不是仅供一个项目使用，而是需要为多个项目提供服务，类似我们前面很多文章都谈到的平台+应用模式，企业私有云PaaS平台建设。在为多个业务子系统提供平台层能力支撑的时候，那个一个关键就是这个平台不会在内嵌在业务系统里面，而是应该独立进行建设和部署，并将平台层的能力通过接口的方式开放出来供上层应用使用。在这种模式下平台层的建设一般会包括如下内容：

1. 独立的门户集成能力，提供门户，统一身份认证，单点登录能力。

2. 提供4A能力，特别是统一用户和统一授权，该能力可以集成在门户中统一提供。

3. 提供公共的流程平台和流程引擎能力，对流程建模，执行，监控数据全部集中在流程平台中管理。

4. 提供一些关键的技术服务能力（其中包括消息，缓存，日志，安全，文件处理等）

5. 整体的UI/UE标准规范制定，开发框架规范和技术制定。

其中1到3基本是一个最简单的公共支撑平台必须提供的，而对于4一开始可以先不提供，由各个业务系统自己去提供和解决。由于上述内容已经抽象到公共平台进行统一提供，因此对于上层的业务子系统开发就更加简单，具体包括的内容为：

1. 提供最基本的核心系统管理模块能力(用户，角色，授权，组织，菜单，数据字典等）

2. 公共技术组件模块(提供一些类似公共函数，缓存处理，日志封装，异常封装，安全等基础能力)

3. 使用统一平台和整体应用架构制定的UI规范和开发框架进行开发

这也是我们常说的厚平台+轻应用的模式，即能够复用和共性的内容尽量下沉到平台统一提供，上层的业务应用开发只需要关注业务流程和业务逻辑实现，而不再需要关心技术的内容。如果再将SOA思路实现的更加彻底，就是上层进一步拆分为业务组件层，和业务组件组装和编排业务层。

由于底层基础支撑平台的独立，上层门户的独立，那么中间就只剩下实现各个业务功能的业务组件模块，而这些业务组件模块拆分好后完全可以实现高度的松耦合的独立自治。而这也是传统架构转为理想的微服务架构的一个标准演进路线和趋势。