随着DevOps、持续交付等理念的深入人心,微服务(Microservices)架构开始走进我们的视野。微服务是用一组小服务的方式来构建一个应用,服务独立运行在不同的进程中,服务之间通过轻量的通讯机制(如RESTful接口)来交互,并且服务可以通过自动化部署方式独立部署。正因为微服务架构中的服务之间是相互独立的,所以不同的服务可以使用不同的语言来开发,或者根据业务的需求使用不同类型的数据库。3月底,来自ThoughtWorks的James Lewis和Martin Fowler分享了他们对微服务架构的理解以及看法。文章中作者详细介绍了微服务的特点以及相对于传统架构的微服务架构的优势。
在James看来,传统的整体风格的架构在构建部署和扩展伸缩方面有很大的局限性,传统的整体(monolithic)风格的架构一般分为三部分:客户端用户界面(HTML页面和JavaScript程序)、数据库、服务端应用程序。服务端程序负责处理HTTP请求、执行业务逻辑、加载和更新数据库数据、查询和填充HTML页面,这个服务端应用就像是一块铁板,笨重且不可拆分,系统中任何程序的改变都需要整个应用重新构建和部署新版本。另外传统的整体风格的架构在进行水平扩展时也只能整个系统扩展,而不能针对某一个功能模块进行扩展。而微服务架构可以完美的解决统一风格架构所遇到的种种问题。微服务架构将系统以组件化的方式分解为多个服务,服务之间相对独立且松耦合,单一功能的改变只需要重新构建部署相应的服务即可。
传统的开发模式在分工时往往以技术为单位,比如UI团队、服务端团队和数据库团队,这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工,不同的服务可以采用不同的技术来实现,一个团队中应该包含开发所需的所有技能,比如用户体验、数据库、项目管理。
传统的软件开发常常以项目为周期,一旦项目开发完成即交付给运维部门,而在微服务架构中,一个团队应该去把控产品的整个生命周期,而不只是开发,这其实也是DevOps的核心理念,所以微