大家项目微服务了吗？

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

最近微信群里有关于微服务相关的讨论，主要围绕是否应该使用微服务、什么时候应该采用微服务架构。有人以为是看人数，所以会问通常团队里有多少人了能够开始使用微服务，好比曾听到有些架构师说大概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到应用层，均可以进行扩容和缩容，既知足业务上高并发可扩展的需求，又能达到合理使用服务器资源、节省公司开支的目的。

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

原文地址：大家项目微服务了吗？