来自ThoughtWorks的主管Neal Ford在最近的一次演讲中表达了他对企业软件系统架构转型的看法，他认为从单体架构转向基于服务的架构要比转向微服务架构来得容易。Ford在UberConf 2016大会上做了一次关于基于服务架构的演讲，基于服务架构是介于面向服务架构和微服务架构之间的一个中间地带。这里可以下载演讲幻灯片（PDF格式）。
微服务架构有很多优点，不过Ford建议应该把这些优点应用在新开发的项目上。对于已经采用了单体架构的组织来说，转向微服务架构有很多问题需要解决：分离代码，分离单体数据库，采用DevOps方法，监控网络，管理分布式事务等。但是转向基于服务架构就不需要做这么多改变，只需要把系统代码分割成若干个以领域为中心的块。基于服务架构可以由几十个可部署的服务组成，并非像微服务支持者们所主张的成百上千个。这些服务可以有独立的数据库，也可以分享单个数据库。Ford认为这是最为关键的不同点，因为他深知在转向微服务架构过程中，拆分数据库是最为复杂的部分。而微服务架构的优点只有在一定条件下才能得以体现，比如每个微服务对它们的数据具有独占所有权，或者有属于自己的数据库存储。
Ford指出，微服务架构也会带来一些复杂性，比如调用关系链以及网络调用隐含的性能问题。单个微服务不管从业务领域方面还是从性能方面来说都很简单，易于理解。但如果是一群微服务，就不是这么回事了。基于服务架构按照领域把更大的代码块组合在一起，减少了网络调用，这样会带来更好的性能。原来可能需要若干个相关微服务的调用变成了单个服务的方法调用。
这种处在中间地带的架构方式是一种折衷的解决方案。微服务架构通过采用DevOps方法，把代码拆分成更小的可部署单元，在交付速度和伸缩性方面得到优化。基于服务架构比单体架构或面向服务架构具有更快的交付速度，它使用微服务架构和面向领域开发拥护者们所推崇的以领域为中心的方式对代码进行拆分。面向服务架构主张根据层而不是领域来对整体架构进行拆分，导致一个简单的业务变更会影响到多个层，需要更多的测试才能发布出去。以领域为中心的架构把测试范围减少到单个要发布的组件上，相比单体架构或面向服务架构交付得更快。要发布的组件越小，测试范围就越小，这就是微服务优化的目标。基于服务架构在提升软件交付速度方面也卓有成效。
最后，Ford在多个方面对几种不同的架构进行了对比。他建议在高度集成的环境里使用面向服务架构，在新开发的项目上使用微服务架构，而基于服务架构主要用于对单体架构系统进行迁移。他认为单体架构不是最终状态。另一个资深的企业架构师Mark Richards，在UberConf上也带来了关于基于服务架构的演讲，他的演讲PPT可以从这里下载（PDF格式）。他们和O'Reilly合作制作了一个深入探讨这个主题的视频。
本文转自d1net（转载）
