转载

孢子框架（微服务）成熟度模型.

笔者并不是微服务领域大牛，但当第一次看到微服务的概念就发现这是社会发展的必然趋势。记得在以前看到过一本书，现在也忘记是哪一本，里面提到将来社会的商业结构将不存在所谓的沃尔玛之类的大超市，而是以微商（个人提供商业服务）为主，那至少是在十年前的提法，当时都感觉不可思议，但现在看来还真有这个趋势。这个趋势和微服务的诞生其实都基于同样的原理：服务结构发展与社会发展同步。社会生产力要发展必须最大化个人的生产能力，所以社会整体生产力的提高的过程也是人的个性化发展的过程。以战争为例，封建社会军队使用人海战术，现在高科技战争使用小团队作战，以将来的科技可能单兵作战都可以灭掉一个国家。

说到这里我们也能看出微服务和传统SOA的区别，就是天猫商城和沃尔玛的区别，也是提倡单兵作战的现代军队和传统军队的区别，也是个体承保责任制和人民公社的区别。这种类比很多，因为基本上将现代的制度和之前的制度做一下对比都会得到类似的结果，这是社会发展的必然。

提到微服务，笔者也不提倡小公司小团队一上来就搞淘宝一样的大框架，也搞不了。但也并不是像某些人讲的那样没有必要一开始就用，那在观念上已经落后于别人了。孢子框架提倡从一开始就实施微服务，甚至没有经验的团队也可以这么做。微服务框架的实施将伴随公司的发展而不断发展，顺应现代社会公司的发展速度。

孢子框架（微服务）成熟度模型.

假设我们开始创业，建立一个小的电子商务公司，只有几个开发人员，那么可以实施孢子框架第一阶段。第一阶段的孢子微服务框架和传统三层架构的单体应用唯一的区别就是以契约型的RPC接口代替进程内API调用。如果说单体应用框架像是家族企业制度（成员间关系密切），那么微服务框架就是现代企业制度。家族企业也可以做大做好，但那是极个别情况，现代企业制度提倡以契约和制度来约束企业中人与人之间的协作，更容易发展和壮大。除了以RPC代替API调用服务外，孢子框架第一阶段提倡进行初步的业务模块初步拆分，这其实跟微服务没有关系，这是基于单一职责的原则，便于将来扩展。对于互联网+的应用，在孢子框架实施后的第一阶段，估计支持100万的用户量是没问题的。

现在公司壮大了，假设用户已经过千万，原有的系统已经超负荷，那么可以实施孢子框架第二阶段。第二阶段主要是体现在使用缓存、异步处理、NoSQL来提升系统性能，以及进行系统监控。由于我们一开始就使用无状态的远程服务接口，所以在第二阶段服务处理也可以进行水平集群扩展。由于扩展了很多个服务器，所以现在需要系统监控及性能监控等功能对服务状况进行监控。如果说第一阶段只是使用了基本的页面缓存功能（如nginx缓存），那么第二阶段需要大量使用缓存功能来最大限度的提升系统性能，这包括高速缓存集群及分布式缓存集群等。第二阶段的用户量可能会产生请求的峰值，因此增加异步处理进行削峰。第二阶段也对应SOA成熟度模型的第二阶段，服务治理需要提上日程。

假设公司业务发展很快，两年内用户过亿，日均PV几千万，此时可以实施微服务的最终框架了，也是现在各个IT巨无霸们提到的服务框架。此时因为用户和业务大量扩展可能已经存在众多服务，可以使用高并发网关或服务框架来协调各个服务。此时某个服务的性能瓶颈可能会影响整个系统，因此某些服务可能采用C++、Go等语言来进行改进。此时服务间的事务协调成为难题，可能需要专门开发一套管理分布式事务的机制和制度。对于实时性比较的高的行业，比如金融，此时可以使用分布式实时计算集群进行数据处理。此时由于服务众多、服务器众多，需要基于docker的自动化部署机制来支持服务的快速部署。

正文到此结束