系统庞大的时候,放在一起开发也好,部署也好,肯定是会有问题的,所以,就出现了子系统,后来又出现了SOA,所谓的面向服务。但到现在,由于网络带宽的提升,BS架构很流行,当然,另外一个方面,现在系统面临的吞吐也大了很多。到现在流行微服务。这种演变的本质就是系统功能太大时,需要拆分,这里面,实际上还有一个因素就是一个系统功能部署在一台服务器上所面临的计算能力问题,这种情况下需要进行分布式处理。分布式处理的基本方法无非就是纵向的功能拆分和横向的数据拆分这两个维度。微服务就是典型的纵向功能拆分。这种拆分当然是有利也有弊。这需要业务和架构师一起决定这个拆分的粒度。这些年的实践经验表明,对于toC的应用可以纵向功能拆分粒度小点,横向的数据拆分可根据具体的服务做具体的决策。单对于toB的应用来说,建议纵向功能拆分粒度大点,而在横向数据分割上下点功夫,这样会好很多。
其实到了现在这个阶段,架构的适合与否一定是基于实际的应用场景决定的,没必要盲目跟风。对于微服务来说尤其如此,特别是服务粒度太小,服务数量多的时候,无论是管理还是运维都是非常大的工作量。大的公司可以玩,一般公司或者创业团队就没必要。只要初期的规范做好,其实到后期上微服务的重构成本,也不是非常高,到一个阶段做一个阶段的事情,太超前的做规划其实是没必要的。