重识微服务架构重识微服务架构
虽然已经红了很久,但是“微服务架构”正变得越来越重要,也将继续火下去。各个公司与技术人员都在分享微服务架构的相关
知识与实践经验,但我们发现,目前网上的这些相关文章中,要么上来就是很有借鉴意义的干货,要么就是以高端的专业术语
来讲述何为微服务架构。就是没有一个做到成熟地将技术传播出来,同时完美地照顾“初入微服务领域人员”,从 0 开始,采用
通俗易懂的语言去讲解微服务架构的系列。所以,我们邀请青柳云的苏槐与 InfoQ 一起共建微服务架构专题“Re:从 0 开始的
微服务架构”,为还没有入门该领域的技术人员开路,也帮助微服务架构老手温故知新。
这是专题的第一篇文章,从最基础的地方入手,让我们重识微服务架构。
前 * 言
得益于 2013 年 Docker 的诞生,微服务概念及架构的推广和落地变得更加的可靠和方便。在 2016 年及之前,微服务架构的
讨论更多的是活跃于互联网企业及社区。现如今,随着 Docker 和微服务架构组件与 Docker 等相关技术的逐步成熟,微服务
架构已然步入传统企业及传统行业。
但是,程序员作为一个理性消费的群体,需要冷静地思考,避免挖个大坑把自己给埋了。所以,我们需要冷静地搞清楚:微服
务(架构)是什么?它有什么优势劣势?我们为什么需要采用微服务架构?如何让老板接受这一新技术?如何落地?如何升级
维护?等等……
我们在过去 7 年智慧城市的建设过程中,研发和交付了很多的大型项目,踩过很多的坑,趟过很多的雷,深受传统建设方法
之苦,也深深被微服务架构带来的好处所感动,我们也将在微服务架构这条路的继续前行。在这里,将我们研发过程中的一些
思考和心得分享给大家,供大家参考。
也许,在不久的将来,软件开发只需要组装,不再需要从头开发。
什么是微服务架构?
形像一点来说,微服务架构就像搭积木,每个微服务都是一个零件,并使用这些零件组装出不同的形状。通俗来说,微服务架
构就是把一个大系统按业务功能分解成多个职责单一的小系统,并利用简单的方法使多个小系统相互协作,组合成一个大系
统。
如果学科派一点,微服务架构就是把因相同原因而变化的功能聚合到一起,而把因不同原因而变化的功能分离开,并利用轻量
化机制(通常为 HTTP RESTful API)实现通信。
追本溯源,Martin Folwer 对微服务架构的定义是:
微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价
值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相协作(通常是基于 HTTP 协议的 RESTful
API)。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外,对具体的服务而
言,应根据业务上下文,选择合适的语言、工具对其进行构建 。(摘自王磊先生的《微服务架构与实践》)
对于我个人,我更喜欢一种延续性的解释,微服务架构 ≈ 模块化开发 + 分布式计算。不管微服务架构的定义怎么样,都是在
描述一个核心思想:把大系统拆分成小型系统,把大事化小,以降低系统的复杂性,从而大幅降低系统建设、升级、运维的风
险和成本。
顺带提一下,亚马逊创始人 Jeff Bezos 在 2002 年就说过:所有团队的模块都要以 Service Interface 的方式将数据和功能开放
出来。不这样做的人会被炒鱿鱼。这才是思路超前的大牛。