java word查重_Java互联网架构-什么样的程序员可以成为架构师

点击蓝字关注我们

欢迎关注微信公众号：java小师妹

周一至周日下午八点

精品技术文章准时送上

精品学习资料获取通道，参见文末

一、初识架构设计

软件工程一般可分为需求、设计、编码、测试、部署、维护。既然架构设计是一个过程，那么就有输入和输出。架构设计输入的是PRD产品说明书，输出的是架构设计文档，中间是处理过程和工具，具体如下：

● 输入：功能需求和非功能需求，从PRD中提取；

● 过程和工具：

● 设计的目标和思路

● 功能设计：用例视图、用例活动图

● 应用：边界、逻辑架构、接口、领域图

● 数据存储

● 物理架构、安装部署

● 非功能设计

● 输出：设计说明书，表述工具有Word、Visio、UML等

需求是我要什么即What，而架构设计是我要怎么做即How。架构设计为施工阶段提供了指导，有利于接下来的编码、测试、部署和维护，包括项目排期、人员分工、配合、单元测试、物理部署、系统修改和升级。设计是施工的计划，没有计划就没有管理，计划可节约施工的成本和时间。如果没有架构设计就开始写代码，会导致很多的问题，干着干着就干不下去了，或干到一半必须得改等等现象。

二、应用架构设计案例

以下是一个真实的应用架构设计案例，《国内航班查询引擎项目》的架构设计过程如下：

2.1 功能清单

产品经理提供的PRD文档做得怎么样，第一眼就看它有没有功能清单。下图的功能清单表格主要有两个核心功能，一个是查询航班数据模块，另一个是清理缓存模块。

2.2 用例图与用例活动图

上图是用例图和用例活动图，用例图有查询航班数据和清理缓存，这与功能清单有对应关系。每一个用例都可以展开为用例活动图，产品经理的活动图关注的是业务的逻辑，我们的用例活动图关注是程序的业务逻辑，有更多的技术视角。如图所示，前台网站或Mobile发起查询请求后，经过参数验证，然后分别获取政策、获取贴点、获取价格、获取航班数据，再合并计算数据，最后构建返回数据。

2.3 领域图

上图是领域图，它从用例活动图演化而来，图中的行为与活动图有对应关系。如图所示，平台或Mobile触发查询引擎后，然后多线程获取政策数据、贴点数据、价格数据和航班数据，然后进行合并计算。领域图是应用程序的业务逻辑模型，它的每一个框有可能是一个类，也可能是一个类库，或是一个应用、一个子系统，它是可大可小、可伸缩、可扩展的。

2.4 接口设计

什么是接口？接口是契约、连接和交互，它是应用与外部世界的联系者。有一位资深架构师说过，“我只需要设计好一套接口，让整个业务流转起来，我的工作就做完了，至于怎么实现我可以不知道”，这话有一定道理。以上契约遵循统一的Request/Response实现模式设计规范。

2.5 分层设计

2.6 代码实现

左上图是第一个版本的代码实现，例如SearchVerify实现验证查询参数、CaculateBusiness实现合并计算、PolicyBusiness实现政策相关逻辑、PriceBusiness实现价格相关逻辑、DiscountBusiness实现贴点相关逻辑、CacheBusiness实现缓存逻辑、UserBusiness实现用户逻辑。右上图是第二个版本，相对第一个版本的实现要复杂些：ValidateBusiness对应验证查询参数、CaculateBusiness对应合并计算、PolicyBusiness对应政策、PriceBusiness对应价格、TiedianBusiness对应贴点、FilterPolicy对应政策过滤。可能你已经发现，不管代码怎么升级改造，只要领域模型没有发生变化，业务模块也就不会发生大的变化。

架构设计会改变编码方式，在架构设计阶段如果做好了领域模型，你就可以在编码施工阶段，先写业务逻辑层再写数据访问层。先定义好业务服务和数据接口定义，再根据数据定义来实现数据访问。这与表驱动的传统方式有所不同。先写数据层再写业务逻辑层，是先写好数据表的增删改查，然后业务逻辑层只是简单地调用一下数据层，便提供给界面层使用。它只是一个简单代理，完全没有发挥业务逻辑层应有的价值。

2.7 其它设计项

除了以上设计项，还有数据库设计、物理架构设计、非功能性设计。数据库设计有E-R图和表设计，物理架构设计有应用集群、应用部署图、域名等，非功能性设计有性能、可用性、伸缩性、扩展性、安全性等。最后是总结和表述，输出一份架构设计文档，详见下图和附档链接。

2.8 演化

以上是架构设计的关键过程，上一环是功能需求，下一环是代码实施，从功能需求到用例图，到用例活动图，到领域图、架构分层和核心代码，以领域模型为中心去构建业务逻辑代码，然后再实现数据库的访问。它们之间环环相扣，做不好领域图可能源自没有做好用例活动图，因为用例活动图是领域图的上一环。从功能到图纸到代码，从代码到图纸到功能，这是一个可演化可追溯的过程。架构设计如同施工图纸，能直接指导工程代码的实施，以及编码施工次序的改变。

三、互联网公司的架构设计要怎么落地

互联网公司的架构设计是怎么做的呢？专职的架构师越来越少，架构部门也大都解散，为什么会是这样，我们该怎么办？

3.1 要不要做架构设计

哪些项目需要做架构设计呢？越大的项目越需要做架构设计，开发时间越长的项目越需要做架构设计，参与人员越多、内部越复杂、外部依赖越多、影响面越大、维护成本越高的项目越需要做架构设计。那互联网的项目呢？它有以下特征：

时间：开发的周期整体很长，可能维护10年、20年，但单个应用的开发周期短，多半以天和周为单位；

规模：互联网项目整体很大，但单个应用规模小，会被拆分为多个小应用；

业务知识：为自己做系统，行业知识不缺，长期为一个系统服务，有些自己也是客户；

复杂度：研发人员多，内部关系复杂，外部依赖多，变化大迭代快，在不断地演化，24小时不间断运行。

3.2 MVP与架构设计

MVP的英文全称是Minimum Viable Product，是最小可行性产品的意思。如上图所示，用户需要一个交通工具，有两种实现方式，第一种做法是分多个阶段设计与制造，第一步是造一个轮子，第二步是造两个轮子，第三步是造一个盖子，第四步是一辆可用的轿车。第二种做法是每一阶段都要满足用户从A地到B地的需求，第一步先造个滑板，第二步是造个自行车，第三步是造辆摩托车，第四步是造辆轿车。第一个版本到第三个版本输出的产品都可以满足用户的基本需求，虽不完善但可以解决用户的问题，并且越来越好，到了第四个版本的产品才是客户预期。

MVP对架构设计提出更高的要求。如果单纯从研发内部的角度，第一种是施工成本较低的方案，但我们需要以客户为中心，需要不断地满足客户的需求，所以在做设计时，不仅要考虑施工的成本，还有客户需求、扩展性、继承性等，如上图第三种设计方案。

3.3 互联网公司是怎么做的

互联网公司的架构设计是怎么做的，当前主流做法有：

分工：将技术研发和业务研发相分离，下层是云平台部或基础架构部，提供IaaS、PaaS中间件等云服务，上层是各业务线的产品研发部，专注于业务场景的应用研发；

敏捷：业务研发敏捷化，产品与研发、测试实时沟通，以减少行业知识的缺乏；

整体：技术委员会，负责技术总体规划和技术成长；

未来：研究院，解决未来的技术问题，如阿里达摩院、百度研究院；

应用架构：主要负责技术与业务的结合，由应用架构师、技术经理或高级程序员担当。

3.4 应用架构要怎么落地

应用的架构设计要怎么落地，常见如下：

总体架构规划：手握地图，才能明确自己所处的位置，以便于配合。总体架构规划可以让每个研发人员了解整体，它如同房子的地基框架图纸，可长期保存和更新维护。具体参考TOGAF开放组体系结构。

单个项目架构设计：重点项目一定要做架构设计，参与架构评审，非重点项目可简化设计表述。

应用架构评审：以流程的方式来保证应用架构设计的质量，例如重构项目、跨部门项目、业务核心项目需要经过应用架构评审之后，才能申请服务器、数据库、域名等。

其它工作：如果有应用架构师专职人员，除以上工作外，还包括统一公司应用分层、制定代码规范、组织技术培训、中间件推广、应用性能调优等。