网站架构师的工作内容( java小师妹周一至周日下午八点精品学习资料获取通道 )

　　网站架构师的工作内容(

java小师妹周一至周日下午八点精品学习资料获取通道

)

　　欢迎来到头条号：java*敏*感*词*姐

　　周一至周日晚上 8 点

　　优质技术文章准时交付

　　获取优质学习资料，见文末

　　一、建筑设计概论

　　软件工程一般可以分为需求、设计、编码、测试、部署和维护。由于建筑设计是一个过程，因此有输入和输出。架构设计的输入是PRD产品规范，输出是架构设计文档，中间是处理流程和工具，如下：

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

　　● 流程和工具：

　　● 设计目标和想法

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

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

　　● 数据存储

　　● 物理架构、安装和部署

　　● 非功能性设计

　　● 输出：设计规范，演示工具包括Word、Visio、UML等。

　　需求就是我想要的，也就是What，而架构设计就是我想怎么做，也就是How。架构设计为构建阶段提供指导，并促进后续的编码、测试、部署和维护，包括项目调度、人员配备、协调、单元测试、物理部署、系统修改和升级。设计是施工的计划。没有计划，就没有管理。规划可以节省施工成本和时间。如果你在没有架构设计的情况下开始编写代码，它会导致很多问题，你将无法处理它，或者你必须在工作中途更改它，等等。

　　二、应用架构设计案例

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

　　2.1 功能列表

　　产品经理提供的PRD文档有多好，乍一看，看看有没有功能列表。下图中的功能列表主要有两个核心功能，一个是查询飞行数据的模块，一个是清除缓存的模块。

　　2.2 用例图和用例活动图

　　上图是用例图和用例活动图。用例图包括查询航班数据和清理缓存，对应功能列表。每个用例都可以扩展为一个用例活动图。产品经理的活动图侧重于业务逻辑，而我们的用例活动图侧重于程序的业务逻辑，更具技术性。如图，前台网站或者Mobile发起查询请求后，经过参数校验，然后分别获取policy、points、price、flight的数据，然后对数据进行组合计算，最后构造返回的数据。

　　2.3 域图

　　上图是一个领域图，由用例活动图演变而来，图中的行为与活动图相对应。如图，平台或Mobile触发查询引擎后，多线程获取保单数据、投递数据、价格数据和航班数据，然后进行组合计算。域图是应用程序的业务逻辑模型。它的每个盒子都可以是一个类、一个类库、一个应用程序或一个子系统。它可以是大的或小的，可扩展的和可扩展的。.

　　2.4 界面设计

　　什么是接口？接口是契约、连接和交互，是应用程序与外部世界的连接。一位资深架构师曾经说过，“我只需要设计一套接口，让整个业务流程化，我的工作就完成了。至于如何实现，我不知道”，这句话有些道理。上述合约遵循统一的请求/响应实现模式设计规范。

　　2.5 分层设计

　　2.6 代码实现

　　左上图是第一版的代码实现，如SearchVerify实现验证查询参数，CaculateBusiness实现组合计算，PolicyBusiness实现策略相关逻辑，PriceBusiness实现价格相关逻辑，DiscountBusiness实现发布相关逻辑，CacheBusiness实现缓存逻辑, UserBusiness 实现用户业务。逻辑。右上图是第二版，比第一版复杂：ValidateBusiness对应验证查询参数，CaculateBusiness对应合并计算，PolicyBusiness对应policy，PriceBusiness对应price，TiedianBusiness对应贴纸，FilterPolicy对应策略过滤。你可能已经发现，无论代码怎么升级，

　　建筑设计将改变编码方式。如果在架构设计阶段准备好领域模型，可以在编码构建阶段先写业务逻辑层，再写数据访问层。先定义业务服务和数据接口定义，然后根据数据定义实现数据访问。这与传统的表驱动方法背道而驰。先写数据层，再写业务逻辑层。数据表的增删改查都是先写的，然后业务逻辑层简单调用数据层，提供给接口层使用。只是一个简单的代理，并没有充分发挥业务逻辑层的价值。

　　2.7 其他设计项目

　　除上述设计项目外，还有数据库设计、物理架构设计、非功能设计。数据库设计包括ER图和表设计，物理架构设计包括应用集群、应用部署图、域名等，非功能设计包括性能、可用​​性、可扩展性、可扩展性、安全性等。最后总结表达，输出架构设计文档，详情见下图及附件文件链接。

　　2.8 进化

　　以上就是架构设计的关键过程。第一部分是功能需求，下一部分是代码实现。从功能需求到用例图，再到用例活动图，再到领域图、架构层和核心代码，领域模型是中心。构建业务逻辑代码，然后实现数据库访问。它们是相互联系的，一个糟糕的领域图可能是因为用例活动图没有做好，因为用例活动图是领域图的前一环节。从功能到绘图到代码，从代码到绘图到功能，这是一个进化和可追溯的过程。建筑设计与施工图一样，可以直接指导工程规范的实施和编码施工顺序的变化。

　　三、如何实现互联网公司的架构设计

　　互联网公司的架构设计是怎么做的？全职建筑师越来越少，大部分建筑部门都解散了。为什么会发生这种情况，我们应该怎么做？

　　3.1 你想不想做建筑设计

　　哪些项目需要架构？项目越大，需要的架构设计越多，开发时间越长，需要的架构设计越多，参与者越多，内部结构越复杂，外部依赖越多，影响越大，维护费用。架构设计。互联网项目呢？它具有以下特点：

　　时间：整体的开发周期很长，可能会维持10年或20年，但单个应用的开发周期很短，多为几天和几周；

　　规模：整个互联网项目很大，但是单个应用的规模很小，会拆分成多个小应用；

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

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

　　3.2 MVP 和架构设计

　　MVP的英文全称是Minimum Viable Product，意思是Minimum Viable Product。如上图所示，用户需要一辆车，有两种方式来实现。第一种方法是在多个阶段进行设计和制造。第一步是造一个轮子，第二步是造两个轮子，第三步是造一个盖子，第四步是一辆能用的轿车。第二种方法是满足用户从A地到B地各个阶段的需求。第一步是造滑板，第二步是造自行车，第三步是造*敏*感*词*，第四步是造*敏*感*词*。造一辆汽车。从第一版到第三版输出的产品可以满足用户的基本需求。虽然不完美，但可以解决用户的问题，他们越来越好。第四版的产品是客户的期望。

　　MVP对架构设计提出了更高的要求。从内部研发的角度来看，第一个是建设成本较低的解决方案，但我们需要以客户为中心，不断满足客户的需求。因此，在设计时，不仅要考虑建造成本，还要考虑建造成本。客户需求、可扩展性、继承性等，如上图第三种设计方案所示。

　　3.3 互联网公司是如何做到的

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

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

　　敏捷：敏捷业务研发，产品、研发、测试之间实时沟通，减少行业知识匮乏；

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

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

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

　　3.4 如何实现应用架构

　　如何实现应用架构设计如下：

　　整体架构规划：只有拿着地图，才能明确自己的立场，方便合作。整体的建筑方案可以让每个研发人员了解整体，就像房子的基础框架图，可以长期保存和更新。有关详细信息，请参阅 TOGAF 开放组架构。

　　单个项目的架构设计：重点项目必须做架构设计并参与架构评审，非重点项目可以简化设计呈现。

　　应用架构评审：以基于流程的方式确保应用架构设计的质量。比如重构项目、跨部门项目、业务核心项目，在申请服务器、数据库、域名之前，都需要经过应用架构审核。

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