浏览器能够解析html、css、js文件，也支持一些图片和媒体文件，通过插件扩展还可以支持更多的文件格式的解析。浏览器支持http协议的通信，所以web服务器也就是返回一些html、css、js和一些图片、媒体文件和一些其他文件的http服务器。

我们的服务端使用的是node，因为语言是js，所以不只限于根据请求的路径返回不同的打包出的静态文件，还可以运行时build。服务器启动的时候build一次，生成的文件放到一个目录下，之后的请求直接返回对应的静态文件。还可以支持服务端渲染，每次请求渲染html和build，考虑到性能要加上缓存。

返回数据的接口也是服务器的职责，我们并没有把之前所说静态文件、渲染和构建的服务器和这部分放在一起，而是单独出了一个api server。render server和api server分离开来以后，职责更加的清晰，易于维护，不过新人可能理解成本会相对高一些。

公司存在着很多产品线，每个项目的技术栈、代码风格都不统一，这会导致很多问题，比如代码的重复、维护的困难等，架构组很重要的一点就是统一这些混乱的代码，所以我们做了一系列的脚手架：mobile、desktop、weex、weight等，同时根据代码规范扩展了eslint、stylelint又写了projectlint。做完脚手架和全方位lint的工作后，技术栈、代码风格都得到了统一，同时业务开发的人员也就不需要深入去学习具体的技术，只需要使用我们的脚手架就可以快速开发。

统一是架构组的一个目的，还有一个目的就是效率，开发的效率、部署到上线的效率等，开发效率方面我们做了组件库、工具sdk，部署到上线的效率方面我们通过electron客户端把需要打开n个网站才能完成的工作集中到了一起，使得部署上线效率大大提高。

最开始的脚手架是只支持命令行的，因为做了构建方面的electron客户端后，我们觉得可以把一些命令也集成进来，比如build、dev、test、lint等，这能解决一些问题，比如打印的信息特别多，找不到想找的信息等。

架构的代码需要完善的单元测试，每一个流程、流程的每一个分支都要覆盖到。

性能也是架构组要关注的，我们基于 google analytics建立了性能监控平台，可能方便的定位性能痛点，然后针对性的优化。

总结

我们服务端用的node，把api server和render server做了分离，render server支持runtime的build和渲染，支持服务端渲染。为了统一各端（mobile、desktop、weex、widget）的技术栈和代码风格做了脚手架和lint工具，为了提高开发效率做了组件库和工具的sdk，提高构建上线的效率做了electron的桌面端工具，同时基于google analytics建立了性能监控平台。端还在扩展，代码还在优化、一些命令也在逐渐地迁移到桌面端工具，可以做的事情还有很多。

开发和架构关注的东西是两个维度的，开发更多的去关注产品、设计、流程、bug等方面，而架构关注的是代码复用、自动化、开发效率、代码规范、技术方案的合理性等。架构的意义除了统一技术栈和代码风格、提高开发效率和构建上线效率、优化性能等方面外，还有很多意义是需要不断探索的。