网站架构师的工作内容(你的公司有没有做架构设计？你认为要怎么做？)

　　网站架构师的工作内容(你的公司有没有做架构设计？你认为要怎么做？)

　　专注Java领域优质技术号，欢迎关注

　　原创：张慧卿 CSDN

　　作者简介：张惠清，IT从业10余年，系统分析师、项目经理。曾任中青易友CTO、同程交通创新科技负责人、固达集团总架构师、携程架构师，带领30-200人的技术团队，研发能力提升1-2个档次。现专注于中小型研发团队的架构设计与工程效率、技术实现与能力提升。

　　你做过建筑设计吗？你认为你应该做建筑设计吗？贵公司做建筑设计吗？互联网公司的架构设计怎么做？

　　不知道大家怎么看，在我得到的回答中，大部分人都想做架构设计，但是很少去做，我经历过的公司也很少做架构设计。

　　这里有一个矛盾，大多数人和公司都会犯错吗？

　　不应该是这样。全职建筑师越来越少，大部分建筑部门都解散了。为什么会发生这种情况，我们应该怎么做？

　　初步了解架构设计

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

　　1.设计目标和想法

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

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

　　4.数据存储

　　5.物理架构、安装部署

　　6.非功能性设计

　　需求就是我想要的，也就是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 设计表达探讨

　　你必须有建筑设计文件吗？是教科书要求的，但现实中可能并非如此，没有设计文档的情况并不少见。您要保存建筑设计文档吗？项目完成后，会保留多久？你工作的公司救了它吗？我们需要冷静下来，问问自己，追求真理比书本更重要。设计文档是为谁准备的？为自己还是为他人？半年是为了自己，还是为了公司或同事？设计可以幸免吗？没有设计文档是否可以编写高质量的代码？如果可以省去文档，那么建筑设计过程呢？

　　建筑设计文件的撰写并不简单，可能需要一周或一个月的时间，而且成本很高。设计的表达方式有很多种，如下：

　　3.2 关于UML

　　UML是Unified Modeling Language的缩写，也称为Unified Modeling Language，是1997年开始的OMG标准。它是一种支持建模和软件系统开发的图形语言，为软件开发的各个阶段提供建模和可视化支持。它不仅统一了 Booch、Rumbaugh 和 Jacobson 的表示，而且进一步发展了它们，最终将它们统一为标准的建模语言。UML图主要有用例图、序列图、活动图、类图、状态图、组件图和部署图。

　　UML 是一种设计表示和建模工具，尽管它的愿景是一个完整的生命周期，甚至使用 UML 直接生成可执行软件。其实这很困难，不真正写代码是不可能把所有细节都讲清楚的。当然，UML在设计过程中还是有一定的作用的，比如序列图、类图、状态图等。如果这些不是用UML图来表示，而是用文字来描述，大家很难达成共识。

　　UML 是理想的建模工具吗？那么理想的建模工具是什么？船舶靠泊行业的3D建模，整艘船在生产前都是在电脑里建造的。塑料建模工具ProE和商品房售楼部的沙盘可以在看到实物之前通过模型了解很多信息。理想的建模工具应该是 3D、动态、简单和可视化的。UML 只是一种表达你头脑中想法的工具。相对而言，头脑中的想法很重要。选择的表达工具要根据双方的实际情况而定。

　　3.3 关于设计模式

　　设计模式是一组重复的、最知名的、分类的、代码设计经验的总结。设计模式用于重用代码并使其他人更容易理解。

　　设计模式对自己、他人和系统是双赢的，设计模式使编码进一步工程化。每个模式都描述了一个反复出现的问题和问题的核心解决方案。在一个项目中合理使用设计模式可以很好地解决很多问题。

　　GoF 中有 23 种设计模式。理解意图是使用设计模式的关键。一张图片胜过千言万语。下面是 23 种设计模式的*敏*感*词*。

　　

　　设计模式是代码的形状，代码结构设计的动作，是实践的套路，就像书是人类进步的阶梯。但是练习就是练习，战斗就是战斗。真正的功夫必须在*敏*感*词*实战中获得。

　　从设计模式到代码，从代码重构到设计模式。设计模式不仅是设计出来的，而且是通过重构“成长”起来的。虽然重构不一定会导致与设计模式完全相同的抽象结果，但重构是对设计模式的迭代补充。

　　过早或不恰当地使用设计模式可能会给代码增加不必要的结构复杂性。重构和模式设计的良好结合使代码更加优质和实用。

　　GoF 设计模式是始于 1995 年的经典，主要是为了解决当时的软件可重用性、可扩展性和可维护性问题。20多年后的今天的互联网时代，版本迭代很快，可以随时在线更新。使用环境、语言和框架都发生了变化。许多模型仍然合适吗？

　　设计模式更多地用于面试还是实际开发中？每个人可能有不同的答案，但每个工具都有其适用的场景、收益和成本，思考这些有助于我们更好地利用它。

　　3.4 关于设计原则 SOLID

　　设计原则是设计模式的关键。原则和方法是决策的思想指南。SOLID的设计原则如下：

　　3.5 关于 DDD

　　DDD是Domain Driven Design的缩写，翻译为Domain Driven Design，其核心是领域模型。什么是模型？装修者从来没有见过你的房子，但是在看了下面的模型之后，你可以看到你会是什么样子。

　　它的价值在于导航、提炼和统一呈现。它可以帮助施工方和客户从各个方面和角度看待问题，而不是盲目地感受大象。它有利于沟通、实施、维护和扩展。

　　

　　什么是字段？

　　Territory 是指领土，而 domain 是指边界。领域是专业的学科，是人为的划分。一个字段有一个边界和一个框。这个领域会随着规模、角度和时代的变化而变化。比如公司很小的时候，没有财务部，一个人既是会计又是出纳。

　　公司做大了，一个可以做会计，一个可以做出纳，可以分为两个领域。公司做大了，领域又变了，成立了财务部。财务部有N个人，每个人做的事情都不一样。业务在变，认知在变，领域的划分也要变。领域是主观的，是对客观世界的阶段性认知。

　　

　　领域模型介于业务问题和技术解决方案之间。首先将业务对象抽象为领域模型，然后根据领域模型实现技术对象。从对象到类到对象，从具体到抽象到具体，我们进一步扩展了抽象和具体。

　　请问，先有鸡还是先有蛋？

　　这个问题不容易回答。如果给你一个具体的鸡和一个具体的鸡蛋，你将能够知道它们是父子还是子父，但是如果给你一个抽象的鸡和一个抽象的鸡蛋，你不知道如何它们是相关的。

　　同样，首先是有一个类还是一个对象？

　　这个问题不容易回答。

　　在设计阶段，有对象，然后是类，在编码阶段，有类，然后是对象。

　　整个过程是：架构师在设计阶段根据业务对象抽象类，然后程序员先写类，再在编码阶段创建对象。从对象到类到对象，从业务问题到领域模型到技术解决方案，从问题域到领域模型到代码实现，这就是领域驱动的核心。

　　领域驱动设计 = 从问题领域推动领域模型构建 + 从领域模型推动代码实现。

　　

　　以上就是DDD的分层架构，包括Repository Layer、Domain Layer、Application Layer、Presentation Layer、Infrastructure Layer。原材料从仓库中取出，然后流水线将人、材料、工具进行整理，最后输出到表现层。

　　上图中，域层不依赖于存储层，但存储层依赖于域层。这相当于传统的三层业务逻辑层不依赖于数据层，而是数据层依赖于业务逻辑层。

　　为什么一定要这样？

　　这是因为上层提供了下层所需要的，而不是下层所拥有的。这就是客户一、按需生产的原则。该技术的具体实现是依靠倒置DIP，把接口放在上层，再实现下层，最后用IoC工具绑定。

　　3.6 设计不足和过度设计

　　什么是设计不足，什么是过度设计？

　　不能解决当前问题的是设计不足；只能解决当前问题的，是合理的设计；能解决当前问题，又能解决未来一段时间的问题，就是好的设计；可以解决当前的问题，但是面向未来的设计太多，过度设计成本高，预测错误，并不能解决未来的问题。

　　我们需要追求合适的设计或好的设计，尤其是互联网项目，变化和迭代很快，很难预测未来会发生什么。

　　那么什么是好的设计呢？

　　好的设计是实用的，通俗易懂的，内敛的，简单的，实用的，性价比高的。一个好的设计需要解决业务问题。不管你的设计多么棒，但它不能解决业务问题，那么这个设计就是一个糟糕的设计。好的设计是审慎克制的，不能为了秀技术或个人意志使用太多复杂的技术。可以实现一个好的设计。如果你的设计在实现中有很多问题，那就是有问题的设计。

　　没有人在设计上失败，只有在实施上失败。

　　3.7 建筑就是艺术

　　以上架构知识很重要，但不代表知道了这些就可以做好架构设计。就像很多人会画圆和直线，但不会画；许多人可以使用钉板和菜刀，但他们无法做出美味的饭菜。

　　让我们讨论一个具体的问题，“尽可能异步”。互联网公司程序员常说的这句话对吗？

　　首先，程序员更喜欢同步还是异步？用户更喜欢同步还是异步？程序员为并发选择异步。用户不等待，立即要求系统返回，会选择同步。

　　那么什么时候用同步，什么时候用异步呢？有几个考虑，首先是复杂度，同步=异步+轮询/通知，同步比较简单，异步比较复杂。二是可靠性。如果 2/5/8 秒的概率很高，那么最好使用同步。三是用户体验。使用异步的时候，用户体验也有待提升，单条数字和进度条可以立即返回给用户。四是业务成熟度。企业成熟度分为四个阶段：起步期、发展期、成熟期和衰退期。对于新的服务，如果能同步就可以同步。当业务越来越成熟，流量越来越大，高并发很可能导致用户排队。这时候异步是一个不错的选择。

　　面对实际问题，选择同步还是异步？

　　这取决于情况，需要分析，思考，你需要知道每个选项的优缺点。分析过程往往比决策过程更重要。当你知道每个选项的优缺点时，你就会喜欢它，因为只有你喜欢它才能把事情做得更好。

　　你的建筑设计=你+建筑设计，建筑设计是科学，你是主观意识，最终的决定必须收录你的个性和情感。科学归根结底就是艺术，建筑设计就是艺术。

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

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

　　4.1 你想不想做建筑设计

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

　　4.2 MVP 和架构设计

　　

　　MVP的英文全称是Minimum Viable Product，意思是Minimum Viable Product。

　　如上图所示，用户需要一辆车，有两种方式来实现。第一种方法是在多个阶段进行设计和制造。第一步是造一个轮子，第二步是造两个轮子，第三步是造一个盖子，第四步是一辆能用的轿车。

　　第二种方法是满足用户从A到B各个阶段的需求。第一步是造滑板，第二步是造自行车，第三步是造*敏*感*词*，第四步是造*敏*感*词*。造一辆汽车。从第一版到第三版输出的产品可以满足用户的基本需求。虽然不完美，但能解决用户的问题，而且越来越好。第四版的产品是客户的期望。

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

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

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

　　4.4 如何实现应用架构

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

　　AppArchDemo案例参考地址：