架构到底是什么？前端架构又是什么？
维基百科对软件架构的定义。
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。
这两句话里可以总结出几个核心名词出来：抽象、解耦、组合，而架构的实际工作，其实就是对这些架构方法和实际场景的梳理把握。
在实际项目层面，高级些的负责整个系统的整体分解服务分层设计等，而中级的架构师，则负责其中某些模块的“系统分析”。
在项目产出上看，分别是 架构图 和 系统分析图。架构图体现的是整个大型服务包含的模块，及其运行关系。而系统分析，则是每个服务内部的具体逻辑以及与外部服务接驳的方式。
前端在整个软件工程中扮演的只是其中的一部分，它的定位较为特殊，不是独立的子系统，却又跨域于整个系统之间。
前端架构的第一层含义：某个系统内部的逻辑抽象和组合
一个公司的前端，必然是分散于各个业务各个系统之间的，反而在每个前端系统内部，又有一套软件工程的思想，比如，针对一个页面进行解耦抽象组合。
前端架构第二层含义：中立于各个系统又植根于各个系统中的前端工程化
工程化的核心关注点是什么？可控，效率！事实上接下来讲的一切都是围绕这两点，由“可控”，我们分化出“开发框架”、“开发规范”，甚至是“脚手架”的一些开发约束，还有诸多“开发流程”和“开发工具”的保障，诸如Review机制和Eslint检查、线上错误报警等。由效率，我们分化出“组件库”复用跨业务的组件，“脚手架”将整个流程封装进几个固定的命令，“mock”系统快速模拟数据等
架构师的工作方式和职责
架构的工作方式
脱离于业务之外后，对自我规划、自我任务和时间管理的要求变高了，要有非常强的自我管理意识。
技术的产出要有严格的流程，因为你产出的是通用方案，要保证技术方案的质量，这时候需要有一套流程，
从“”发现问题“” 到 “”调研" 到 "初步方案" 到 "评审确认可行性" 到 "详细架构系统分析" 到 "开始编码" 到 推广到文档。
之前一整个项目组一起做的流程，现在可能都落到了你自己的头上，看似繁琐但是却是必要的，因为你是一个专业的架构师。
通常程序员通常比较厌恶这种流程上的事情，喜欢自己捣鼓研究敲代码，殊不知其实对于程序员来说最简单的事情其实就是敲代码，如果你一直想敲代码不想做设计/规划/推广，那绝对是在精神上偷懒。而有挑战的事情是什么呢？是设计，设计数据结构，设计组件，设计解决方案。更有挑战的则是将这些设计做完美，做通用，并落地。
架构的职责
宏观上，把控整个团队的技术选型和技术栈，技术发展方向。这看似是一次性的工作，但是却需要持续优化的。例如推动整个公司向Vue或者React转换，推进ReactNative的实施，需要架构师对这些技术栈有深入的了解，能够正确的权衡选型，评估风险，并且给出切实可落地的方案。
各个技术栈的技术体系。业务开发的技术体系，包含脚手架，开发框架，开发规范，组件库，配套工具等。细说起来其实是个挺庞大的事情，每一部分都可以展开成一个话题。
例如脚手架，其实是在管理规范或者简化一个业务项目从创建到开发到调试到测试到发布的整个过程（通常会做诸多定制）。
例如开发框架，抛开底层的mvvm框架，上层需要做封装，将一些难以理解的概念或者写法繁琐的东西封装起来，同时糅合一些强制的开发规范，还有就是通过框架层规避开发中可能会出问题的风险点（例如数据类型转换之类）。这里提到的每个点可能都是个大工程，而且可能会有好几套体系，例如我司前端的 Vue 体系，客户端的 React Native 体系，服务端界面的 React 体系等。其中有些体系甚至要做到让不是前端的开发去写前端，稍后我会介绍，其封装、规范、工具需要做到简单强大的程度可想而知。统一环境管理，开发发布流程制定等。制定公司统一的前端开发方式/流程，中间可能会需要一些工具来提高开发效率，推进这些工具如何融入流程被大家接受等。还有前端开发需要的测试、预发、线上环境资源管理的方式、权限等。例如在我们团队中，RN的发布集成上线过程其实非常复杂（为了做版本锁定）但是业务开发需要做的事情可能就一两步而且非常简单，这种维护方式转化成最终集成结果，把复杂的方案包装成极简的使用方式，这也是架构的重要职责之一。
提供特殊解决方案，例如服务端渲染，可能原理不难，但是需要有专人将其构建成低入侵、高性能、高可靠、统一的服务集群，业务可以非常低成本的接入，并且不需要关系其运维、可用性、性能等问题。其他例如 数据统计打点、跨端调用等，都需要做一些统一的封装处理，让业务方方便使用。
提供一些特殊的工具和系统，例如性能收集，错误收集，mock系统，在线调试，可视化编辑，短链管理等。
提炼业务中除了UI组件之外公用的部分业务，独立维护，我们称之为业务SDK，例如跟金融相关的钱包业务，数据业务，聊天业务，全景业务等，都会作为独立的业务系统服务于其他业务。
前端开发体系
得益于快速迭代的业务，搜车的前端技术栈统一是Vue2.0，从移动端到PC端，从B端业务到C端业务到营销业务，所以整个体系都围绕Vue2.0展开。大概罗列一下体系中的组成。
脚手架，定制自官方，糅合项目管理规范、版本管理规范、配置管理、开发发布流程等。
开发框架和规范，目前这块做的比较弱，后续准备做一些深度的封装，做好分层的约束，甚至是请求方式、数据映射等，主要是减少业务项目中的不确定性风险，同时简化开发过程。
组件库，包括两端的UI组件库，功能库，还有一些独立于组件库之外的组件（例如图片引用库，会自动根据环境切换webp，并且能优化图片大小，自动实现延迟加载）。在这方面我们投入的精力也比较多，我们有组件准入规范（规范设计师的设计）、组件开发规范（规范组件的开发过程，确保质量和一致性）见附图。
开发工具，mock系统（自动从后端接口定义生成随机mock数据，Easy Mock），错误收集系统（所有端如有必要均用Sentry收集），外部链接管理（一个短链服务）。
跨端调用，Tower.js + 客户端SDK，可以在所有app内使用各种Native功能，例如照片，视频，用户信息，截图，分享，视图栈管理等等。
服务端渲染方案，可以低成本接入任意项目，有专门的监控运维性能优化。
静态资源托管服务，基于Nodejs的一个支持部分动态功能的静态资源服务，有一部分服务则会直接通过nginx托管。另外静态资源服务的发布方式，权限管理等相关的脚本和系统。
后台系统页面开发方案
为了前后端完全分离，技术栈采用了 vue2.0全家桶+element-ui组件库+axios请求库
NodeJS开发体系
NodeJS除了给自己提供的基础体系以支撑业务之外，还需要给团队输出一些工具和解决方案。简单介绍下。
自己的Node 开发框架，约定各种分层接口定义校验，自产的ORM，还有一些内网协议适配，队列系统，定时任务等。
前端的一些通用解决方案，例如服务端渲染，无痛接入前端业务，做好运维报警性能优化等底层。还有短链这种体系，为前端开放出去的链接做分组数据管理等。
总结
一个好的架构师必然有自己的一套工作习惯，清楚地知道自己的职责，知道自己应该关注的重点，利用自己的经验和方法来控制风险、简化开发、提高效率