感谢图灵社区的电子书阅读奖励计划。
作为一个前端，这本书看得有些吃力，很多在作者看来属于基础性的知识比如SOA、RPC，我一点概念都没有。
但这并没有妨碍我理解作者要表达的意思，从这一点看来就觉得这本书很有价值了。
虽然平常工作不会涉及到后端，更不用说服务设计，但这本书中的很多理念，在前端也是有参考价值。
架构师
书中介绍了作为一个架构师，应该做什么。
在前端是否存在架构的争议下，是否团队中存在一个职责与之类似的人，就可以认为前端也是存在架构呢？
分区
后端将服务划分成多个区分别进行管理，在前端与之类似的则是网站也是分为多个区域，这里不是指页面程度的划分，也是服务。
公司发展到后期，网站的规模越来越庞大，不可能几百个页面的代码在一个仓库中维护，而是会安装功能拆分出多个，但他们又是同属一个网站。
不知道这种算不算架构师要考虑的？
原则性的方法
与后端严格的代码规范相比，前端要宽松许多，加上前端框架繁荣（笑），对某个框架的最佳实践还没有定论，使用vue还是react，使用react的话需不需要状态管理，redux还是saga亦或者是mobx？
这就更加导致了不同区的代码存在不一致的实现，从这点来看，如果架构师能提供最佳实践当然是最好的，这么看来还是蛮佩服后端架构师。
实践
后面的内容，以一个虚拟的MusicCorp例子来具体描述在真实世界，我们可能会遇到的问题以及该如何做。
编排与协同
当一个事件发生，编排的做法是由一个中心大脑，分别向多个服务发出请求；协同则是由中心大脑发出一个事件，不同的服务注册该事件即能够得到响应。
在基于vue或者react的组件化开发方式，就存在类似于编排与协同的问题。
在商品详情页面，当用户点击商品模块加入购物车，就改变商品数量这个状态，购物车模块接收该状态作为props，所以页面维护的商品数量改变后，购物车模块也同步发生改变，这在我看来就类似于编排。
而协同呢，我觉得是很像redux的实现，reducer作为中心大脑，商品模块被点击后，就向中心大脑发出了一个“加入购物车”事件，购物车模块则订阅了该事件（connect 并且 map 商品数量），所以购物车内的商品数量也发生了改变，商品模块与购物车模块不需要在同一个页面，而其他新模块也能够接收该事件。
更多
后面的部分，由于后端的特性需要考虑部署、测试、监控等等，在前端也是类似，从中能够得到借鉴。
总结
这是一本即使不是后端开发也能够有所收获的书，如果准备实践微服务设计，那这本书更是必看不看。
网友评论