很久很久之前我听说了SOA,我不知道这是干嘛的;很久之前我听说了微服务架构,我又不知道这是干嘛的。我就一直在问我自己现在的项目架构很落伍么,我怎么感觉它还是能满足我的需求的呢;新的架构能解决我的什么痛点,他们提到的现有的架构的缺点我没有感觉到,他们提到的新框架的优点我也不以为然。想了好久之后,我突然明悟:我的项目不适合这个架构。
先说结论:微服务结构为大型项目(几十个人、几十万行代码)或多技术架构而生
微服务架构:
微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建 (
马丁 -福勒)
优点:1)易于维护:拆分成小的服务之后,业务变得纯粹,新功能开发、缺陷定位修复较简单。
2)缩短交付周期短:不会因其他的业务或需求而影响本服务的交付。
3)新人培养周期短:新人来后,第一时间了解和参与项目是很重要的,而一个较小的服务则在代码或业务逻辑上都易于理解和部署。
4)技术选型灵活:我们现有的一种主流语言可以解决绝大部分的需求,但是并不是百分百;现在日益涌现的新技术也证明了他们的价值,在一个旧有项目上应用新技术,应用的大小就成了关键所在。
微服务结构的优点都来自于服务的拆分,那么另一方面,拆分的缺点也是微服务的缺点:
缺点:1)运营麻烦:体验过维护很多个项目的人都了解部署很多个应用的麻烦
2)基础共用性:项目的简单与否在于是否有扎实的基础。分成很多个应用之后,基础的共用便是一个很大的问题。
3)拆分依据:即使满足上面的条件,拆分仍然是一个很大的难点,只懂理论是无法解决现实中遇到的各种各样的拆分问题的。不合理的拆分会让上面的优点都变成缺点。
为什么我的项目不适合微服务结构:
1)技术单一:我的项目属于偏业务型系统,技术比较单一(正在积极采用新的、更合适的技术)
2)项目较小:一个业务线项目的日常维护和开发人员不到五个,可想项目有多简单
所以,对于我这种简单的项目,微服务架构是没有什么用武之地的。
所以,再说一遍,微服务结构有用,但是是为大型项目(几十个人、几十万行代码)或多技术架构而生