@citian3094
2016-09-06T09:09:32.000000Z
字数 5001
阅读 1344
架构师 架构 王福强 微服务 docker
2014年由Martin Fowler与James Lewis共同提出微服务开始，伴随着以Docker为代表的容器的兴起，微服务+容器时不时被当作一组话题被架构师们提及，既然微服务和容器技术拥有令人兴奋的潜力，那么在实践过程中会产生怎样的效果以及面临怎样的挑战呢？
2016年12月2-3日，ArchSummit全球架构师峰会将在北京举行。本届大会组委会策划了微服务与容器实践专题，并邀请了独立技术顾问王福强老师担任出品人并对该专题进行把控和策划，我们借此机会采访了王福强老师，他为我们分享了有关微服务和容器实践的一些见解和经验。
受访嘉宾介绍：
王福强，A Writer, A Fighter, A Programmer And A Teacher，《Spring揭秘》和《SpringBoot揭秘》作者，原挖财技术VP及首席架构师，原天猫资深架构师，原阿里巴巴高级技术专家；浸淫Java平台多年，然近年更喜Scala，专注于并发并行编程、HPC、分布式系统设计与实现、Big Data、实时数据追踪与计算等领域，相关Web Framework、 DDAL(Distributed Data Access Layer)、Middleware的Product Owner/Co-owner。互联网和金融领域涉猎居多，参与并领导过包括信贷、债券、外汇(保证金)交易等多种金融系统的设计与开发工作。
InfoQ： 能否谈谈您目前作为独立技术顾问的工作和职责？您经历过阿里巴巴高级技术专家、天猫架构师、挖财技术VP等职位后，为什么做了这样的职业选择？
王福强：应该说独立技术顾问只是我短期内的工作，不能称之为职业选择，现在更多是在看项目和方向，一旦项目和方向确定，将会全力投入到新的工作中去。不过既然说到这里了，也不妨分享一下我这段时间做独立技术顾问的经历和感悟。
很多公司希望找技术顾问，实际上他们可能只是希望找一个技术上的战术专家，他们遇到什么问题，希望技术顾问帮助他们解决什么问题，偏trouble shooting层面较多，这个层面的顾问工作我也可以做，但不是什么核心价值。很多时候，一个公司在技术层面表现出的种种问题，本质上引发这些问题的根源往往不在技术本身。所以我做技术顾问不会一上来就扎进去技术细节当中去，而是从业务到团队和组织结构，再到技术这样的步骤进行梳理和诊治。
以当前朋友公司的案例来讲，他们公司做对B业务，但作为创业公司，即使是对B业务也会迫于营收目标和压力扩展好多条产品线，相应地为了支撑这么多产品线也扩充了技术团队来构建相应的支撑能力。随着技术团队的扩张，团队的技术文化氛围、技术选型的多样性和复杂度都被稀释并扩散。可以看到：业务层面的决策导致的问题会外延式的向下游扩散，从而导致更多的问题，可以说所有的问题都可以归结为业务上的问题，而不是技术上的问题。
为了应对这个问题，我（甚至该公司的董事会讨论之后也做了同样的决定）建议收缩产品线，集中兵力在核心的产品上，即根据业务的调整对现有团队和组织结构进行优化，将团队职责边界划分清楚（该公司还有两地研发中心的问题，通过划分职责边界可以一定程度上减少两地研发中心管理上的劣势），然后才是跟进团队结构，对技术选型和规划落地进行更加细粒度的诊断和改进。
当然， 具体到每一家公司可能执行层面都需要根据情况进行微调，但总的方针和方向应该是类似的。
InfoQ：作为资深的Java技术专家，为什么“近年更喜Scala”而成为Scala的布道师？
王福强：最初接触Scala是因为发现这个语言从哲学和使用上都比Java简单，而且同样是运行在Java虚拟机之上，那么Java生态下的很多东西就可以延续复用，Java的生态配合Scala语言的简洁性可以极大地加快应用的研发和交付，这或许是当初更加喜欢Scala的原因吧！
但事无完美，实际上在使用的过程中还是会发现很多需要注意的问题：
Scala的大版本升级一般是二进制层面不兼容，所以写依赖库的时候最好使用Java来写；
Scala语法和特性上给予了太多灵活性，但随之也会带来接受上的复杂度，对于应用研发者来说，最好只用基本的一些语法，少炫技，毕竟代码是给人看的；
Scala社区过于激进，如果将Scala语言作为一个产品来看待，那么作为产品的owner，如何让产品更加易于被用户（即我们这些programmer）接受，应该是owner多加关注的事情，现在一个不好的现象是：产品的owner更多是从语言的实现角度来阐述这个产品多么简单，而不是从使用者的角度。我认为正确的做法应该是从使用者的角度来简化语言的设计，而至于如何高精尖，如何复杂地实现这个语言（比如编译器的设计和实现）则是随后要考虑的事情，Problems First，Solutions Second！
虽有不完美，但我还是会选择Scala作为应用开发的首选语言，因为这个场景就是适合它！因为了解，所以喜爱，因为喜爱，所以愿意为之倾倒进而宣导，这可能就是选择做Scala的布道师的原因吧！
InfoQ：您认为互联网金融公司与电商公司在架构设计或在选择技术栈思路上有什么共同点和不同点？金融更多强调安全，在架构设计上会着重考虑哪些环节？
王福强：我不敢确定我说的是否正确，但个人认为：不管什么类型的公司，从架构原则上来讲应该是没有本质差别的，至于说技术栈的选择上（甚至架构的实践上）那就不一而足了。
有的公司技术选型是由行政主导的，例如很多传统企业、政府机关等，这种情况居多吧？有的公司技术选型是由团队成员决定的，团队的骨干因为可以完全掌控某种技术选型，所以可以很大程度上cover后期的风险，配合"民主集中制"，这种类型的技术选型方向是比较合理的。
还有的公司技术选型可能只是人云亦云拍脑袋决定的，这个我就不好举例了。
安全是一个比较广的概念，所以我只能肤浅地谈点儿个人架构设计上的一些思考，权当抛砖引玉吧！好的架构设计可以很大层面上帮助预防一些安全问题：
借鉴军事上“深度防御（Defense In Depth）”原则，从网络安全、应用安全、系统安全多个层面构建安全防护网，使得攻击者的攻击成本和复杂度逐步上升，毕竟所有的事情最终都会归结到经济成本上；
通过平台化的思路，将可以预想的安全场景固化到类库、框架和平台产品中，首先解决掉80%以上的问题，然后通过日常安全工作来弥补剩下20%的安全场景；
最后，无论多么好的思路和设想，都需要通过团队内部和团队之间的协作使之落地才算大功告成！
InfoQ：微服务将单一进程传统应用拆分成一系列多进程服务，是否意味着开发、调试、测试等各方面复杂度增大，如何应对？能否结合数据谈谈微服务改造后对系统架构有哪些好处？
王福强：微服务到底是给团队带来复杂度还是带来效率的提升，一切都要看微服务的实施时机。我一直强调一点，假设公司基础设施建设和支撑跟不上，那么最好暂缓微服务的实施，当然能够“小米加步枪”硬是撑过去也不是不可能的，只是不要一厢情愿地非要因为概念时髦非得上。
我觉得一个比较好的建议是：对于那些明确可以知道后期需要持续投入资源并可以复用的服务和模块，是可以一开始就考虑微服务化的，而对于那些更加偏前端业务且业务方向处于探索期的，最好不要一上来就做微服务化，会导致不必要的成本。
从产品交付的历史上看，传统软件研发和交付模式与互联网软件研发和交付模式可以一定程度上类比Monolith类型软件研发和交付模式与微服务之间的效率差别。
过去我们要以年为单位进行传统软件的迭代，而互联网时代，我们则是以周、天、甚至小时以及持续交付作为迭代频度，虽然从中长期的目标来看可能双方的目标是一致的，但迭代速度明显不是一个数量级，不知道这种数据对比是否可以说明问题呢？
当然还是要强调，高频的迭代，是以雄厚的基础设施建设为基础的。
InfoQ：Docker容器技术是实践微服务架构的最佳解决方案吗，为什么？微服务哪些问题目前还不能用Docker解决？
王福强：应该说，Docker容器技术与实践微服务架构并无必然的联系。不用Docker我们依然可以使用现有成熟的技术搭建一套完备的微服务架构体系，使用Docker可以在某些环节替换现有体系中的某些职能的实现，并让某些环节的效率更好一些罢了。
微服务的问题需要由微服务体系自身规划和落地的时候来解决，Docker跟这些没有必然联系，甚至也无法解决。Docker在某些微服务基础设施不完善的场景下会帮助一定程度上提升交付效率，但正规的Docker实施，应该对微服务的交付是无感知的，Docker应该作为支撑微服务体系基础设施的一部分来实施，以提升资源利用率为第一要务。
InfoQ：微服务化实践中你们曾在Java轻量级框架中选取了SpringBoot而不是Dropwizard，上升到技术选型时，您认为除了技术生态社区外还有哪些因素需要重点比较？推动技术在各部门落地方面您有什么经验可以分享？
王福强：因素很多，但我独关注两点：
团队中是否有骨干可以很好地掌控某种技术选型，有，则上，没有，不好意思，选择社区成熟、使用范围广的那种；
项目的发展和趋势，单人研发或者社区不活跃甚至停止更新的项目，慎用，我不会以技术实现的优秀与否作为技术选型的重点决策依据。
其实“推动技术落地”中的“推”有“强迫”的意味在里面，这种做法会收到一定的成效，但无法普遍适用，毕竟要让某项技术选型在所有部门落地，需要所有部门的研发同学都能够接受并帮助落地，没有谁愿意被迫做某些事情。
我觉得要做好技术选型的落地可以转变一下思路，以服务性思维来推动某种技术选型的落地，即能不烦扰各部门的就不要烦扰他们，能够帮助他们做掉的事情就由推动方尽量多地做掉，减少落地部门的接受成本，这样要比硬逼迫各部门配合收到的效果好。当然，对于说服不了、服务再好也不接受的部门，强迫就强迫吧。
InfoQ：微服务有多“微”？如何避免单个服务过大或过小，这方面是否有实用的衡量标准？能否举例谈谈你们以什么维度拆分服务，是否遇到无法拆的场景，如果有应该如何解决？
王福强：我只能说从我的见识来看，微服务到底要多“微”，到底要如何拆分，没有一定的定规，但从领域模型出发，逐步划分边界并拆分是一个比较好的实践方式。最主要的，我们不能为了拆而拆，对于那些复用度不高，随时可能因为业务方向变更而丢弃的服务和代码，还是随它去吧！
微服务是否落得好，全凭实施者在实践过程中的拿捏，有个词用来形容这种拿捏是否恰当，即“手感”，所以拼到最后，还是各位实施过程中的手感。
InfoQ：微服务架构入门学习曲线是否陡峭，微服务对创业团队友好吗？您认为技术团队什么阶段或者具备怎样的条件后可以考虑尝试微服务改造，或者遇到哪类高频出现的问题时可以考虑微服务？
王福强：我没法说微服务对创业团队是否友好，因为创业团队也分很多种，对于一上来就战斗力超群的明星团队，微服务落地应该不是什么难事，对于其他类型的创业团队，则更要具体情况具体分析了。
我的建议是小步快跑，不用一上来就等万事俱备，积跬步致千里嘛， 不走，肯定永远到不了。如果有1-2个人（也可以兼职）可以帮助团队构建横向支撑性的技术基础设施，应该可以很大程度上减少创业团队实施微服务的痛苦。
对于明确需求的，且被很多服务和引用方依赖的关注点，可以开始就考虑微服务化并落地掉，避免后期改造重构的痛苦。
InfoQ：对于目前没有条件实践微服务的团队，您认为可以建立哪些开发思想或文化以面对未来需要改造的可能，以达到未雨绸缪降低成本的目的？
王福强：微服务应该说在软件行业不算是颠覆性的理念，如果一家公司现有的技术体系和基础设施建设已经很完备了，我相信接纳和迁移微服务的成本很低，而且如果一家公司的某些系统复杂度到一定程度之后，被逼迫走的路可能自然而然就是一条微服务化之路了。
但作为一家公司的技术负责人，一定要系统性地考虑整个技术团队的交付效率，要知道某些横向的建设局部无效但整体却会很有效的道理，什么时候要调整组织结构，什么时候要调整资源投入，技术负责人的手感很重要，手感好的技术负责人会因为整体上的规划可以在问题来临之时轻易消弭之。
InfoQ：感谢王福强老师接受我们的采访，期待ArchSummit全球架构师峰会上您策划的微服务与容器实践专题。