“微服务并不是一切”：Fred George谈论技术性、流程性与组织性障碍
2016-03-02 17:50:11   来源：Daniel Bryant ，译者 邵思华   评论：0 点击：

在microXchg 2016大会上，Fred George进行了一场主题为“微服务并不是一切”（It’s Not Just Microservices）的演讲。他在演讲中表示，微服务确实能够帮助组织“发展得更快”，并快速地交付商业价值。但他认为， 微服务的实现本身并不会带来成功，必须找到在技术、流程和组织等方面对业务的敏捷性增长造成阻碍的原因，并冲破这些阻碍。

George是Fred George Consulting公司的首席顾问，他在演讲的开头部分首先表示，当前业界存在着许多“热门话题”，例如微服务、Docker和精益创业，这些话题都是围绕着更快地交付商业价值的意愿而展开的。通过对于Cynefin框架的引用可以发现，许多组织所开展的业务是非常复杂的，由于这种复杂性，而无法确定因果关系，并且“目前有效的做法未必今后也同样有效”。因此，如果期望在应对这种复杂性时能够做到“更快地发展”，就必须找到在技术、流程以及组织方面的发展障碍并消除他们。

George引入了技术性障碍这一概念，为了详细地讨论这一问题，他首先对“硅谷科技”的爆炸式发展进行了探索。在硅谷地区，有大量成功的商业组织充分地应用了云计算、专用数据库、开源框架与持续发布等技术，这就让其他组织开始反思，是否他们自身在技术方面的选择阻碍了他们的发展。尤其值得一提的是，如果组织将应用程序的部署从数据中心的裸机迁移至虚拟化的云平台以及基于容器的环境，那么就能够减少硬件的交付周期，进而缩短了应用的部署周期，这种差别往往是指数级的。

George认为，由于硬件的交付周期缩短，再加上现代化的硬件平台具有更好的灵活性，这将促进服务设计的发展。久而久之，IT产业的革新者逐渐开始从单一的一体性应用转变为由多个大尺度的面向服务架构（SOA）组成的服务。这一趋势最终演变为由多个小规模的单一职责（微）服务所组成的系统，由此带来了简化代码变更、缩小迭代规模以及更快的实践等优点。

通过不断发展的技术，我们将能够创建松耦合、高性能的应用架构，例如使用（利用Kafka等技术）持久化事件总线，并通过一个轻量级的消息代理（messaging broker）以减少对于核心事件总线（通过ZeroMQ等技术实现）的读操作的负载。在同样由George所主持的另一场演讲“实现微服务所面临的挑战”（Challenges in Implementing Microservices）中，他还将对这一概念进行进一步的探索。

George为听众举了一个车辆租赁业务领域方面的应用示例，该应用通过某个服务向事件总线发送一条消息，基于客户的数据发起一条租赁报价请求。而其他服务则能够对该请求发出出价的回复。通过这种松耦合、异步消息驱动的架构，就可以轻松地添加新的出价服务（例如某个开发者认为他们实现了一种改进型的出价算法），并且由于单一的出价服务不会造成整个系统出错的涟漪效果，从而也提升了系统的容错能力。

在关于如何缓解技术性障碍的讨论的总结陈词中，George提出了开源所带来的爆炸性优势，如果组织无视一些现有的技术，例如Netflix OSS技术栈或Docker，那么就可能会将资源浪费在开发自有平台上。此外，George还表示，对于某些用例来说，函数式语言或许能够成为解决问题的“银弹”。他提到了一个有趣的案例，某组织将一个包含13万行代码的Java遗留应用重写为基于Clojure的应用，仅用了4千行代码。

在演讲的下半部分，George讨论了如何缓解流程上的障碍，而解决这一问题的关键在于首先要理解组织所开展的业务。对于明显或有一定复杂度的项目，可以通过传统结构的软件开发方式应对。但对于高复杂的问题则必须采用不同的策略。传统的“瀑布”模型的做法是在项目开始时为开发团队创建一个需求列表并进行任务分解，这种方式并不适合于处理复杂的问题领域，而应当采用“由实践驱动创新”的方式，开发者应该转而关注于“特性”层面，而不是继续停留在任务层面。

项目干系人应当直接与开发者讨论需要达成的业务目的、如何评价业务的成功，并且清晰地指出开发团队可以选择的“手段”。这一过程的关键在于“衡量重要的指标”，避免使用一些无用的指标，例如“代码行数”以及“完成的里程碑”，而应当使用一些专注于业务的指标，例如销售量、点击次数以及客户保留率等等。

在George谈论如何缓解组织性障碍的开始，他提出了一点建议，即应当避免开发团队任务的过度专业化。他发现，虽然理论上专职人员具有更好的生产力，但往往会受到过多的沟通与不均衡的工作安排的干扰，由此造成了工作的堆积与延误。George为听众展示了某个组织的工作过度专业化的学习案例，他同时认为：各种漂亮的头衔对于项目的业务价值交付毫无意义。

我们有50位IT专家，其中超过25人有较高的头衔，但没有一个人理解他们所参与的项目的意义……

对于这个学习案例中所表现的过度专业化的问题，George提出了一种解决方式，即创建一份简短的清单，列出对于组织有战略性重要意义的关键技术，并基于新手、熟练工及专家的模型创建相应的头衔。在这个学习案例中，新创建的头衔包括：“新手开发者”，即还未掌握某项技术的人员。“开发者”，即掌握了某项关键技术的人员。“高级开发者”，即某项关键技术方面的专家。“系统开发者”，即掌握了5项或更多关键技术的人员。以及“开发者专家”，即3项或更多关键技术方面的专家。

除了头衔的简化之外，另一个关键在于组织的工作空间的安排，这种安排的目的是让团队能够进行密切的合作，并且保证高效的沟通。团队应当实现“不设立专职主管”，以避免在团队中出现无谓的上下级结构，并且在处理因复杂的问题而出现不断变化的挑战时，这种方式能够带来更大的灵活性。而George所提的最后一条建议是“将工作安排给固定的团队”，因为短期项目团队的组建与解散是一种低效的方式，团队需要一定时间才能够达到较高的生产力。

George在本次演讲的总结中说道，虽然对于复杂的业务领域来说，微服务是一种解决问题的好方法，但只有处理好其他技术性、流程性与组织性障碍的问题，才能够有效地利用微服务交付商业价值。George最后向参加此次专注于开发者的microXchg大会的听众传达了一条信息，他表示在开发团队中必须有系统管理员与运维人员的参与（“DevOps”），并且应当拥抱全栈开发者的观念。

Fred George在microXchg的演讲“微服务并不是一切”的视频可在大会的Youtube专属频道上观看。

查看英文原文：“It’s Not Just Microservices”: Fred George Discusses Technology, Process and Organisation Inhibitors