一、么是微服务?
微服务可理解为一种新的软件架构方法。
传统的软件架构被称为单体架构系统,也就是说整个应用最终被打包成一个部署包(如war包)进行部署。这种架构易于开发、测试和部署,但在扩展性、可靠性上上有较大的不足。特别是在功能庞大且不断扩展的情况下,开发、维护、性能上都有较大的缺陷。在设计上,单体架构系统通常以技术分层,譬如逻辑层、数据层等。
微服务是指从业务角度出发,将完整的功能分解为一个个小型的服务(如订单管理、账号管理),每个服务都有自己的处理和轻量通讯机制(通常是基于HTTP协议的RESTful API),可独立开发(采用不同开发语音、不同开发框架)、独立测试、独立部署、独立升级。
微服务更倾向于围绕业务功能对服务结构进行划分、拆解。这样的服务,是针对业务领域有着关完整实现的软件,它包含使用接口、持久存储、以及系统间的交互。因此这个团队应该是跨职能的,包含完整的开发技术:用户体验、数据库、以及项目管理。
二、微服务的核心
l 小, 且专注于做一件事情
l 独立开发、测试、部署、升级、维护
l 每个微服务都有自己的存储能力,可以有自己的数据库
l 轻量级的通信机制(Restful API)
l 松耦合
三、微服务与SOA
SOA实现 | 微服务架构实现 |
企业级,自顶向下开展实施 | 团队级,自底向上开展实施 |
服务由多个子系统组成,粒度大 | 一个系统被拆分成多个服务,粒度细 |
企业服务总线,集中式的服务架构 | 无集中式总线,松散的服务架构 |
集成方式复杂(ESB/WS/SOAP) | 集成方式简单(HTTP/REST/JSON) |
单块架构系统,相互依赖,部署复杂 | 服务都能独立部署 |
四、微服务开发示例
(一) 架构设计
以一个租车系统为例。使用单体架构设计的系统结构如下:
使用微服务的思想设计的系统结构如下:
一个微服务一般完成某个特定的功能,比如下单管理、客户管理等等。每一个微服务都是微型六角形应用,都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI,运行时,每一个实例可能是一个云VM或者是Docker容器。
每一个应用功能区都使用微服务完成,另外,Web应用会被拆分成一系列简单的Web应用(比如一个对乘客,一个对出租车驾驶员)。这样的拆分对于不同用户、设备和特殊应用场景部署都更容易。
每一个后台服务开放一个REST API,许多服务本身也采用了其它服务提供的API。比如,驾驶员管理使用了告知驾驶员一个潜在需求的通知服务。UI服务激活其它服务来更新Web页面。所有服务都是采用异步的,基于消息的通讯。微服务内部机制将会在后续系列中讨论。一些REST API也对乘客和驾驶员采用的移动应用开放。这些应用并不直接访问后台服务,而是通过API Gateway来传递中间消息。API Gateway负责负载均衡、缓存、访问控制、API 计费监控等等任务,可以通过NGINX方便实现,后续文章将会介绍到API Gateway。
这种微服务架构模式深刻影响了应用和数据库之间的关系,不像传统多个服务共享一个数据库,微服务架构每个服务都有自己的数据库。另外,这种思路也影响到了企业级数据模式。同时,这种模式意味着多份数据,但是,如果你想获得微服务带来的好处,每个服务独有一个数据库是必须的,因为这种架构需要这种松耦合。下面的图演示示例应用数据库架构。
每种服务都有自己的数据库。另外,每种服务可以用更适合自己的数据库类型,也被称作多语言一致性架构。比如,驾驶员管理(发现哪个驾驶员更靠近乘客),必须使用支持地理信息查询的数据库。
表面上看来,微服务架构模式有点像SOA,他们都由多个服务构成。但是,可以从另外一个角度看此问题,微服务架构模式是一个不包含Web服务(WS-)和ESB服务的SOA。微服务应用乐于采用简单轻量级协议,比如REST,而不是WS-,在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也拒绝使用canonical schema等SOA概念。
(二) 微服务之间的通信方式
通过使用HTTP/REST,数据格式使用JSON 或 Protobuf(Binary protocol),通讯协议是自由的。
五、优点
l 每个微服务都很小,这样能聚焦一个指定的业务功能或业务需求。
l 微服务能够被小团队单独开发,这个小团队是2到5人的开发人员组成。
l 微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的。
l 各个微服务能使用不同的语言开发。
l 微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如Jenkins, Hudson,bamboo 。
l 一个团队的新成员能够更快投入生产。
l 微服务易于被一个开发人员理解,修改和维护,这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
l 微服务允许你利用融合最新技术。
l 微服务只是业务逻辑的代码,不会和HTML,CSS 或其他界面组件混合。
l 微服务能够即时被要求扩展。
l 微服务能部署中低端配置的服务器上。
l 易于和第三方集成。
l 每个微服务都有自己的存储能力,可以有自己的数据库。也可以有统一数据库。
六、缺点
l 微服务架构可能带来过多的操作。
l 需要DevOps技巧(http://en.wikipedia.org/wiki/DevOps).
l 可能双倍的努力。
l 分布式系统可能复杂难以管理。
l 因为分布部署跟踪问题难。
l 当服务数量增加,管理复杂性增加。