@qinyun
2017-12-18T14:08:32.000000Z
字数 5643
阅读 1877
未分类
宋一玮，毕业于北京理工大学，曾供职于IBM、Amazon以及一家O2O创业公司，现任FreeWheel基础架构部门主任工程师，负责FreeWheel自有前端框架SparkUI的设计研发和推广。从最早的ASP、JSF、Flex、Dojo，一直到移动端、Angular，以及现在FreeWheel使用的React.js，从事前端开发已有10年。
在InfoQ主办的全球架构师峰会北京站2017上，FreeWheel基础架构部门主任工程师宋一玮老师发表了《FreeWheel在微服务架构下的前端改造实践》的主题演讲，我们在宋老师的演讲中了解了SPA架构能力、新旧前端架构渐进改造能力、前端自动化测试的重要性等重要知识。为了进一步了解FreeWheel的前端改造过程，我们邀请宋老师做了专访，以下是采访的内容整理。
宋一玮：你好。
宋一玮：
SPA是在近几年前端比较流行的架构，我们知道传统的前端会有MVC这样的架构，而这些架构，更多出现在之前的单体的Web应用里面，或者一些纯客户端的应用。在这些年里，随着这个框架如React、Angular，或者Vuejs的兴起，SPA的架构越来越成熟了，我们会通过这样的架构首先为用户提供一个无缝的体验。什么是无缝？以前我们的页面是要一页一页刷新的，但是，当我们就引用SPA架构以后，用户看到的页面就没有明显的刷新了，它只是一块一块加载，加载完了以后会有Loading的indicator，然后可能会有内容出来，这样对用户是一个不间断的、非常流畅的体验，这是在我们体验层面上的。然后在架构层面上，刚才也说到了MVC，现在我们可能更加强调View加上单向数据流这样的架构，这样的架构的好处是可以处理越来越复杂的前端交互，让整个Web应用更像一个全功能的客户端的应用。
从开发角度来讲，这种架构会给我们提供一些更加工程化的实践的能力，我们以前的JS或者前端的开发都非常碎片化，但是在引入我们SPA架构后，我们可以工程化地开发，不同的同事在同一个前端项目里边可以并行不悖，做自己的模块，在特定的节点去整合，这样，开发与维护的效率都非常地高。再就是部署还有上线以后的运维，它的难度都比之前传统的单体应用之类的要低很多，这是我对SPA框架大概的看法。
宋一玮：
刚才其实在会上问答环节里面也提到了，是不是说SPA架构就一定要用到微服务体系里面去？其实答案并不是绝对的，我们首先要有一个需求，我们想要整个企业的产品有这种演进，那我们会提出一个要求：我们前后端更加解耦合或更加灵活一些，那我们就会把后端和前端做一个分离。至于后端，存在各种各样的需求，导致我们去选择微服务这样的体系架构。对前端而言，当然要配合这样的架构，如果它还是像刚刚讲到的Ruby on Rails这样的单体应用的话，它就会带来一些额外的负担，变成传统架构的额外负担，所以我们要采取一些新兴的架构来去搭建前端。这是我们做这样选择的动机，但之后我们在真正实现当中总结出了很多一些所谓最佳实践的东西，比如说我们后端服务既然做了这种切分，就是微服务了，可能有多个这种服务，它的上线不能随意，是比较灵活的。
前端也可以做成多个微服务，做成多个SPA，这样它也会比较灵活，比如说前端的SPA上线的时候，我们可能配合两三个微服务上线，或者说另一个微服务上线的时候，我要上线两三个SPA，这样它的排列组合就会非常灵活。当我们选择这样的框架在一起的时候，就会产生了一些很有机的的化合反应，我们觉得对整个产品的演进是有很大帮助的。
宋一玮：
这是一个很好的问题，因为在软件行业重复造轮子是为很多人所诟病的，但在当时，我们并不是头脑发热去做这件事情的，而是我们在做前后端分离这样改造的过程中，在前端逐渐积累这样经验的过程中，我们初期选型用了React，我们其实初期也在用Flux这样一些官方推荐的如Facebook官方推荐的这样框架，但是我们遇到了我在演讲过程中提到的各种各样的限制，一些不能满足的地方，虽然用了一些业界新型的中间方案去Workaround这样的问题，但是对我们而言，这可能不是有效的方式，所以我们会逐渐去搭建一些更有用的框架出来。当我们发现这框架已经逐渐成型的时候，它也变成了一个自研框架了，甚至其中一些地方已经达到可以发布开源的版本了。
宋一玮：
这个框架可以分成几块，首先，就是它的Modulajs，Modula是状态管理的框架，这个框架基于Redux，当然也可以不基于Redux，它可以提供应用状态的管理，同时，它可以基于Immutable Model Tree来提供这样的功能。这样的话，我们用Immutable Model Tree方式就可以很好地展现你的业务模型，同时，我们还可以把我们一些行为挂在这个模型上，同时我们也可以通过这些Model tree去很好地处理我们前端常遇到的Side Effect，这就是我们说Modula带来的好处。同时我们也会有若干个这样一些可重用的组件，这些组件也是在商业应用领域解决了很多我们自己提出来的需求，包括刚才也提到了比较高质量的要求和一些国际化的一些要求，还有一些精度的要求，这是它的优势所在。
宋一玮：
实际上，我们作为技术人并不是在纯粹地在研究一项技术，我们研究这项技术的原因是要把它用于业务，用于业务意味着技术方案要落地，所以实际上我们很多时候要脚踏实地地去做技术的设计，最终可以实现业务。同时，我们很多时候包括我自己也做过很多这样的短平快的设计和实现，这些实现能满足当时的需求，但往往造成一个结果，当我的业务在进一步演进的时候，产品经理或者服务团队提出了更高的要求时，我们突然发现这段代码白写了，我们要重写，那这是不是说一开始做短平快方案的时候少考虑一些什么样的东西？实际上你的设计和技术的实现需要往后考虑。有时候你会发现你的产品已经足够到前面，你的技术已经掉队了，整个团队都有寸步难行的感觉，当产品经理提出需求，我们会需要越来越长的周期才能满足，这个时候我们就要奋起直追，把技术赶到一个业界比较前沿或者比较流行的状态，这样的好处就是我们能更好地维护，拿到的资源会更多，同时能更好地招人，因为用十年前的技术去招一个人是比较困难的。
宋一玮：
好的，因为我是研发出身，并不是我刚才演讲里面提到的研发出身的QA，也不是QA出身的那种研发，虽然我是研发出身的从业人员，但是近些年我主要写单元测试和写自动化测试，我深刻地体会到自动化测试的好处，之前，比如说我完成一个功能时，我要手工去点一二三四五，没问题，开发一个功能我点一次，上线就好了，但是会有很多机会是让我重新去点一次。比如，我的同事他改个东西，他有可能碰到代码，那代码是我要自己再测一遍，实际上这是个问题，所以说我希望我这个测试是可以被重复的，而且是非常低成本的，所以我会做自动化测试。当时演讲现场也有些朋友提问题说，我们公司到现在还是有很多专职的QA同事，这是一个很好的状态，我并不否定它，但只是说像我之前会上说的，对不同的公司可能有不同适用的一些领域，像我们这种公司的话，我们是非常尊崇自动化测试。
宋一玮：
这个是很有意思的一个话题，因为在我们微服务改造过程中，我并没有直接去参与到里面的过程，但是我们跟微服务的团队是紧密配合的，当时还有很多有意思的事情，比如当时我们微服务做出来一个版本，但是我们前端可能还没有做SPA的改造，那微服务怎么上线呢？比如Ruby on Rails应用里边开一个接口，这个接口后面就是微服务，然后前面再设个开关，上线的时候，其实Rails和微服务都上线，开关如果打开的话，走微服务，开关如果关闭的话，走Rails老的代码，所以说这样的过程给了我们之后的工作一个很好的启示。我们可以通过这样的方式做这种逐步的、新旧并存的演进，这实际上就是说我们在这种演进过程中微服务团队和我们前端团队相互配合，或者互相地启发。就微服务的最佳实践来说，在早期的时候，我们决定要走微服务这条路的时候，就要有一些我们比较信得过的、经验比较丰富的同事站出来，去把选择所谓的框架，然后制定代码的标准，把最后上线维护的方式定得很清楚，我们再基于这些标准去开发样板工程，当我们的样板工程上线以后，给整个公司一个强心剂，一个定心丸，OK，我们可以放心走这个路了。
对于前端也是这样的，我们也是把SPA做到一定状态时，邀请一个团队，一个业务团队，完整地用SparkUI开发一个功能，开发完以后，做了样板工程，全公司都很信服这一点，我们就可以这样走。
宋一玮：
因为我们SparkUI一直在尝试解决商业应用的，里面的SPA架构解决我们这样实际的一些需求，同时，我们认为，只要跟我们类似的商业应用一定会有一些相似的需求，就这些需求而言，也许我们框架就非常适合他们。他们可以用我们的框架解决这些问题，解决这些需求，所以我们确实也很着急地把这个框架Open Source出来，然后也非常希望这个框架能被一些业界开发的朋友真正用起来，在用起来过程当中他们可能会给我们提一些反馈，我们就知道我们并不孤独，我们有很多朋友，经过这样一些反馈，我们就可以把这个框架做得更好，既能满足我们自己公司的需求，又能满足这一类应用在业界里面的需求。再具体一点来说，就是编程接口的易用性，比如说整个框架的性能，然后还有刚刚会上提到的，比如说国际化、安全性这样所有的一些事情我们都可以在开源的体系下做到更加的Open，更加开放，争取能为开源社区做一个回馈。
宋一玮：
这个问题确实很有意思，因为我做前端有段时间了，刚才说10年了，因为我最早接触的时候是Flex、Adobe Flex，有些朋友之前可能也用过它，它的整个设计，还有框架的接口是非常好用的，当时这种浏览器框架可以提供非常好的富客户端的体验，这是非常棒的。但是从技术的演进上面来讲，它是失败的，因为它只有一个厂商在控制，所以最后大家就抛弃了它，它并不是因为技术本身被抛弃的，而是一些其他方面的因素，我们知道在这个市场上，我们确实会有很多好的技术，可能会一直发展得很好，也有可能会因为非技术的原因突然倒掉，前端这个领域确实有很多技术消失了，但不断有新的技术出来，比如这几年的React、Angular、Vuejs，还有一些可能之前没有那么火，现在突然变火起来的functional programming，这都是一些趋势。就这些趋势而言，会一波一波的过来，比如之前移动端有iOS开发、安卓开发，现在有很多所谓大前端、三端代码复用，比如在React开发视图，然后它的代码可以run在Web上面，可以run在iOS上面，可以run在Android上面，这样的代码复用，虽然可能有些问题，但它在特定场景下是非常适用的，所以实际上会形成一个所谓的分离和融合的过程，就各种前端领域都会有这样的一个过程。比如说VR和AR，也会跟我们现在的这种基于浏览器的体验形成统一或者融合，我是会比较相信这一点的。
而且我们现在也看得到Web浏览器以Chrome为首，还有Firefox，现在这种浏览器的能力是越来越强，包括最近发布的WebAssembly，我们甚至可以用C去写网页上面的一些功能，这个是非常厉害的，同时，我们会非常有信心地说我们到时候会有更加适合的技术来做更加适合的事情，而且很多会发生在浏览器上面。
宋一玮：
好的，因为我在这10年当中也做过一些管理的工作，当时有些年轻的同事，他们有过类似的疑问和想法，我首先的看法是，对一些相对年轻的朋友来说，前端并不是一个隔离的东西，它一定是一个兼容并包的东西，你的一些开发或设计很有可能会涉及到后端，我们传统说的后端，会涉及到云，甚至会涉及到大数据，我建议不要惧怕，可以把自己的眼界放得更宽一些。虽然我现在的工作是前端，我积累的这种经验都是前端的东西，但实际上很多东西是相同的，我觉得可以把眼光放得比较开一些，当我去做各种各样的积累时，比如做后端的其他积累的时候，我再做前端的话就更加游刃有余了。请记住一点，虽然前端的技术演进非常快，我们要多去了解它的why，不能光看它的how，他们为什么会有这样的新技术出来？它的初衷和目标是什么？你就会想到这个技术可能和以前某个技术是类似的，但是因为我们浏览器技术的发展，或者计算能力的加强，它有了一个新的展现，你会发现你以前一切的积累都没有浪费掉，这是我对年轻的朋友尤其是刚毕业的朋友们的建议。前端就是Vuejs，有很多人这样说，因为中国Vuejs的流行是非常广的，但我会担心，如果你作为一个前端的研发从业人员，你只会用Vuejs的话，你的发展有可能受限，我建议把它铺开了。