转载

你们项目微服务了吗？

微服务这几年很火，做后端开发的，如果没听过微服务，出去见同行都有点不好意思的。那么大部分后端开发人员都应该听说过了，但真正用过的，可能就少一些，这也可能是因为公司的旧系统一直能正常工作，没有推翻改造的必要，也可能是团队人员对微服务不熟悉，不敢尝试新的技术架构。不管怎样，我们一般提倡，合适的就是最好的，别管它是否时髦。

最近微信群里有关于微服务相关的讨论，主要围绕是否应该使用微服务、何时应该采用微服务架构。有人觉得是看人数，因此会问一般团队里有多少人了可以开始使用微服务，比如曾听到有些架构师说大概100人以上的团队适合采用微服务，另外一些人觉得是看业务，就是怎样的业务适合采用微服务。

而在我们看来，单纯从人数或业务的角度去看是否该采用微服务架构，都不太理想，而如果着眼于整个系统的业务特点、部署方式、协作模式，相对会好一些。

比如你的业务模块种类比较多，如果采用微服务的话，只要定义好服务间的接口，就可以做到团队里不同的人同时进行不同模块的开发，也就是并行开发。如果你的系统在一段时间内需要进行扩展，比如一个服务需要部署多份，并且分布到不同的机器上面，这样采用微服务也似乎更合理。如果是单体架构，这个时候的扩展，就需要对整个单体进行扩展，而微服务架构，只需要对其中某个小服务进行扩展，可以节省CPU和内存资源。从协作角度来看的话，也跟团队规模有关，确实是团队规模越大，采用微服务好处也越明显一些。如果是几个人的团队，模块划分粒度又比较大，这个时候的微服务架构，跟单体架构也没有太大的区别，不过采用微服务架构，仍然可以起到为今后扩展而设计的目的。

微服务架构中的服务发现和治理、服务监控、配置管理等，不同框架都有不同的组件来完成，稍微学习一下也可以用上了，并没有太高的门槛，当然如果想特别深入，还是需要花很多时间。以我的亲身经历举个例子吧，我曾经在没有使用Java做过任何项目的情况下，去帮忙一个小公司搭建他们的后端技术架构。因为他们听说Java技术栈比较成熟，后端希望采用Java开发，而我也为了能够在Java方面多一些实战经验，于是就是用三天的时间去熟悉了Spring Cloud框架，然后给他们搭建了后端的微服务系统，用到的组件大概有Spring Cloud Config、Eureka、Feign、Zuul、Ribbon、Hystrix、Sleuth、Zipkin等。团队里也只有几个开发人员，基于我搭建的技术框架，进行应用服务的开发。这些框架组件和应用服务都是用Docker进行部署，部署到阿里云的容器服务上，目前运行起来各方面都良好。

我采用Spring Cloud为他们搭建后端开发框架，一方面就是刚才提到的也是为了让自己多熟悉Java和Spring Cloud框架，另一方面是他们的业务特点属于可能短期内流量暴增的类型。而我觉得微服务架构在可扩展方面有较大的优势，可以较好地应对这种问题，然后基于Docker的部署方式，可以实现服务的弹性伸缩，因此整个系统从基础设施层IAAS到应用层，都可以进行扩容和缩容，既满足业务上高并发可扩展的需求，又能达到合理使用服务器资源、节省公司开支的目的。

总的来说，就是我们倾向于从业务特点、部署方式、协作模式角度去考虑是否采用微服务，而不是跟风，看到别人使用了新技术，自己也非要去用才不显得落伍。况且微服务也并不算什么很新的技术，它只是以前的应用架构发展到一定阶段自然衍生而成的，然后也具有了之前应该架构不具备的一些特点。如果你的旧系统运行得很好，或者准备开发的新系统不需要我前面提到的那些特性，那可能维持现状或者采用单体架构就挺好，遇到确实比较适合微服务的项目，再采用也不迟呢。

微信扫码，进入【技术人成长】社群逛逛。