架构师和架构设计

曾经有句调侃的话“十个人九个是经理，还有一个是副经理”形容头衔的泛滥，而今更进一步经理升级为“总”了。 与此类似，在 IT 技术圈架构师也越来越多了。包括各种级别的， 高级，资深，首席。也可以看到做着各种不同范围工作的架构师，有的只写 PPT 的， 有的还要编码，写测试用例，给老外维护老旧产品的架构师，兼着项目经理的架构师。 一次以前同事的聚会，一堆 IT 老男人还是饶有兴趣地讨论一些技术问题， 自然免不了提到架构一词。 席间一位发问，架构设计具体包含哪些工作？ 呵呵， 大家之前没有正式思考整理过，也没即席得到一个全面的答案。就在这整理一下， 我现在的名片上也印着资深架构师，先要自己明白自己的工作。

架构设计包含几个方面。大家对架构师工作范围彼此认知不一致，多半是因为事先没有界定究竟是哪个方向的架构。一般来说分四类业务架构，应用架构，数据架构，基础架构。以下一一描述。

1.      业务架构。 主要的工作是梳理业务需求，确定业务活动流程。其中一个重点是确定业务流程涉及的职能部门或者工作人员角色。 每个职能部门或者人员的角色职责，和哪些业务活动节点相关。职能部门和相关人员的组织结构，上下级关系，或者在业务活动中的交互关系等。整理业务活动流程中流转的数据信息。将众多的业务活动流程划分为若干个业务系统，包括抽取出每个业务系统中共同的业务流程，构建出新的业务系统，为其他业务系统提供支撑。确定在各个业务系统之间交互的数据信息。业务架构设计是业务人员的工作，但 IT 人员也需要很细致深入地了解。

2.      应用架构。 有了业务架构分析结果，就要考虑怎么样构建应用系统来实现这些业务需求。对应若干个业务系统，自然会有多个应用系统。应用系统和业务系统可以是一一对应的，具备相同的边界，也可以不对应。 一般为了复用，功能集中的要求，会设计很多细粒度的应用系统。另外也会有一些新的对应技术层面需求的应用系统，比如监控系统，集成总线，前置系统等等。要定义这些应用系统的接口和调用接口的规范，确定各个应用系统相互交互的内容和过程。

        对于一个应用系统，要设计由多少个应用程序，或者客户端 API 库组成。每部分各自实现什么功能，分布在多少个节点上，彼此怎么交互。 每个程序的层次结构，线程驱动的应用逻辑流程。还要选定实现应用系统的技术手段。 以前都是代码实现，运行在操作系统上，所以需要选择使用什么编程语言实现，运行在什么操作系统上 ; 之后越来越多的技术层面的需求被归纳抽取实现为中间件作为应用的开发和运行平台，为开发应用系统节省了时间，提供了基础功能支持，提供了新的应用逻辑实现手段。消息中间件提供分布式环境下应用的异步消息交互功能；交易中间件实现分布式事务；集成中间件提供不同数据协议和接口技术之间的转换；流程编排工具可以让开发者不用编写程序，而是用图形化编排流程的方式实现审批工作流或者自动流程；规则引擎帮助应用来做规则判断和推理等等。

      使用中间件平台开发的应用程序可以有两种运行方式。一是作为独立的程序运行，自己还是需要编写 main 函数，只是调用了中间件的功能；另一种是程序实现为一组组件运行在中间件平台的容器里，程序本身不用编写 main 函数。应用服务器上的 EJB 组件， ESB 上的服务都属于第二类。这种中间件平台容器提供应用的部署管理，监控，以及其他多种功能，使得应用开发比较方便快捷，但也付出了放弃自由独立的代价。

      完成应用系统功能的设计，还要考虑应用系统的性能，负载能力，如何方便地做处理能力的扩展。 确定应用的部署方案， HA 或者是负载均衡模式的。性能，负载处理能力经常会成为应用系统运行中的问题，应用系统为了满足性能和扩展性需求，往往要做很多不规范的设计实现。这些设计实现经常会打破应用系统本来的架构和层次，让程序变得面目全非，这是系统运行多年后常见的无奈状况。好消息是随着虚拟化技术的发展，我们可以在所谓的云平台上开发应用而不必关注扩展性等问题。虚拟而容量无限的计算资源，操作系统，存储系统，缓存使得我们的分布式应用系统彷佛变成在一台超级计算机上的一个超级应用程序。无论负载处理要求怎么提高，应用程序本身不需要做什么修改，甚至不用重新部署启动，应用下面的虚拟平台提供了应对负载处理能力扩展的计算，存储和内存的扩展。当然这是最理想的模式，目前革命还未成功。

    除了要考虑性能上的扩展，还需要考虑功能上的扩展 。系统要模块化设计，松耦合，数据结构要留有扩展位，程序要用设计模式，这是最基本的要求。还有目前已经深入人心的SOA， 要求设计的系统具备开放性，遵循统一的服务接口，一方面便于以后被其他系统复用，一方面也方便调用已有系统的功能。总之为了以后有新的功能需求，能够快速实现。良好扩展性会让设计出的系统在更长的时间内保持先进性，不被淘汰。

      在这里需要提一下，应用系统的管理和监控。 每个应用程序需要有管理监控的接口，每个应用系统都要实现管理和监控功能。监控的重要性不亚于应用本身需要实现的业务功能，在做应用架构设计的时候，监控是需要非常重视的内容，设计监控实现甚至优先于设计功能实现。现在的应用系统都要求能够实时监测，能够改变运行时应用程序的参数，实时的控制。

      还有一个重要的内容，应用系统集成。 集成可以划分为几个层面，应用界面集成，应用接口集成，应用数据集成。其中应用接口集成包括应用功能接口集成和应用监控接口集成。现在企业内部异构系统越来越多，标准的做法是搭建集成总线，使得这些异构系统可以方便的互联，相互调用彼此的功能，交互各自的数据。同时越来越多的客户希望有一个集中的监控系统能监控更多的企业内部的应用系统，监控这些应用系统从技术到业务层面的各种状态信息。接口技术通常有文件， API ，端口加数据协议，消息中间件消息（ MQ, RV, JMS ），各种 RPC 技术（ EJB, CORBA,COM, SOAP ）等等，现在的集成总线产品都支持这些接口技术，支持连接一些常用的软件套件。

 

3 ．数据架构。 数据其实是应用的一部分，单独列出来总以见其重要性。数据是业务领域的实体和操作在应用系统里的数据结构定义。 设计数据的难点在于现实世界这些实体和相互作用的复杂，实体的继承关系，集合关系，实体的分类 都是比较难梳理清楚的事情。很多成熟行业都有行业内部的数据协议，在做数据架构设计的时候，有现成的数据定义是最好了，即使不完全遵循标准，也能提供很多的参考。如果逻辑层面的数据定义完成，那之后的工作就要简单一些。把这些数据对应于各个应用系统使用的数据库和数据库里面的表单视图；应用程序内部的数据结构和对象定义；应用系统交互时的网络数据包等等。 其中数据库的设计是大型应用系统的重中之重，需要详细地设计每个数据库，每个表单和视图，确定每个数据库的容量和性能要求。需要梳理清楚多个应用系统和多个数据库之间的关系。

对于企业的多个应用系统而言，如果在设计之初有统一的数据架构设计，就避免了之后大量繁杂的数据交换和数据整合工作。当然这是理想的情况，现实是这些之后的整合工作不可避免，现在时行的 EAI 中间件， ETL 软件， meta data 管理和 master data 管理产品就是做这些工作的。

 

4.       基础架构。基础架构包括数据中心，灾备中心，网络架构，信息安全管理等等 ，这几部分知道的比较少，就不再这发表论述了。对于做应用和数据架构设计的架构师，对基础架构还是要有所了解，这是应用系统所处之中的环境。

 

   总之架构师的工作比较广泛，而每个架构师真正能做的和精通的就不多了。