这几年在Java工程师招聘时,会看到很多人的简历都写着使用了Spring Cloud做微服务实现,使用Docker做自动化部署,并且也会把这些做为自己的亮点。而比较有趣的这其中以小公司出来的人为绝大多数,大的公司出来的人简历上倒是很少提这些东西。
对于我自己来说,从15年就开始关注这一块,看过马丁.福勒最开始的关于微服务的论文、也看过不少对微服务的论证的英文文章和书,也研究过Spring Cloud、Sofa等开源实现以及Service mesh。考虑到我们公司研发团队人力不足、基础设施不完善,当初是没有推行微服务的。但随着看到上述的那种简历越来越多,有时候我也会疑问:难道真的不用微服务就落后了吗?公司的同事如果不掌握这些就真的没有竞争力了吗。而随着最近公司业务的逐步提升,研发人员越来越多,借着在梳理公司的微服务落地计划时,也梳理了一下微服务的相关知识点,也是本文的主要内容。
开篇之前先声明我对微服务的几点态度:
架构模式有很多,微服务不是唯一的选择也不是什么银弹。
国内绝大多数中小公司引入微服务都是在盲目追新,也能看出做此种技术选型的工程师基础架构素质的不足。
“你必须长的足够高才能使用微服务”。
微服务基础设施,尤其是容器技术、自动化部署、自动化测试这些不完备,微服务形同虚设,不会带来什么质的提升。
微服务架构的关键不在于具体的实现,而在于如何合理地划分服务边界以及组织架构是否相匹配。
不考虑研发团队的规模和组成就盲目上微服务是不良的技术选型。
Spring Boot是Spring全家桶的上层封装,并不是什么崭新的技术,也不是什么值得觉得成为自己杀手锏的技术。
Spring Cloud中Spring Cloud Netflix的组件是经过生产环境验证的,其他的则建议慎重选择。
微服务是什么
微服务起源于2005年Peter Rodgers博士在云端运算博览会提出的微Web服务(Micro-Web-Service),根本思想类似于Unix的管道设计理念。2014年,由Martin Fowler 与 James Lewis共同提出了微服务的概念,定义了微服务架构风格是一种通过一套小型服务来开发单个应用的方法,每个服务运行在自己的进程中,并通过轻量级的机制进行通讯(HTTP API)。关键的三点是small、automated以及lightweight。
对比SOA,微服务可以看做是SOA的子集,是轻量级的SOA,粒度更细的服务,独立进程、数据分离,更注重敏捷、持续交付、DevOps以及去中心化实践。其共同的架构原理:
-
单一职责
-
关注分离:
控制与逻辑相分离
-
模块化和分而治之
特点:
-
用服务进行组件化
-
围绕业务能力进行组织
-
是产品而非项目
-
端点智能化和哑管道: 控制逻辑都在端点,管道仅仅是传输
-
全自动化部署