在今年的伦敦微服务大会上， Ian Cooper 在演讲中为听众描述了从一体性架构转至微服务架构的一些指导原则。在他看来，架构的转换对于业务干系人来说唯一的价值就在于成本的降低。它既不会增加或保护你的收益，而可伸缩性与分布式的特性也不是能够说服业务人员的好的理由。之所以这种架构转换能够减少项目的总体成本，是因为开发人员在转换后的架构中所面对的将是相对较小、较简单的上下文，从而提高了他们的生产力。
Cooper 也是伦敦.NET 用户组的创建者，他指出：人们在提到微服务的时候通常会连带提起业务能力，但对于业务能力的概念很少有清晰的定义。在他看来，业务能力本质上就是某个业务为客户所提供的有价值的功能，例如保险公司的保险销售业务。业务能力通常来说是非常稳定的，但这种能力也通常表现在一个较高的层次上。Cooper 随后将这些业务能力转换为边界上下文（这一概念来自于领域驱动设计）的形式，使他们的表现更为具体。
在一体性的架构中，同样也存在着多个边界上下文，但他们会对资源进行共享，例如领域对象和数据库架构。这样一来，就造成了系统的各个部分之间的依赖性。一个功能的变更很可能会产生涟漪效应，影响到系统中的其他功能，这意味着系统的每一部分必须共同进行编译与部署。要将这样的架构转换为微服务的环境，你所要做的一切就是将这些互相依赖的功能分解为各自独立的边界上下文。虽然说起来简单，但Cooper 认为实现起来并不容易。
Cooper 描述了一种从一体性架构转换为微服务架构的方式，即对系统进行全部重写，但对他来说，这也意味着这一项目从敏捷变为了瀑布式工作流。其原因在于整个系统的替换必须要做到功能性的完整，新的系统必须在完全容纳了老系统的功能后才能上线。这样一来，新系统的开发在很长一段时间内将无法获得任何用户反馈，对于系统的表现只有在上线后才能了解。这样的项目往往会因为长时间内无法交付任何商业价值而被砍掉。
与上一种方式相比，Cooper 所建议的方式是找到在整个业务中产生产生最多价值的特性，例如那些能够产生市场差异化、属于关键任务的特性、或者是变更快速的特性。Cooper 接下来将这些特性逐个替换为新的代码，这种方式能够让他将某个边界上下文中的功能替换为新代码。最后，该上下文中的所有旧代码将失去功能，并被移除出系统。最终，到了某一时间点，所有的功能都将得到替换。在 Cooper 看来，这种方式的优点在于它保持了项目的敏捷性，通过增量式的架构重构以管理风险，并且能够更早、更频繁地进行交付。
来年的伦敦微服务大会计划在2016 年11 月7 日至8 日举办。
查看英文原文： Moving from a Monolithic to a Microservices Architecture
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论