微服务的基本概念

微服

monolithic(单体)架构概念 vs. 微服务架构概念

    monolithic架构指的是应用被以单一单元构建。比如一个小型订餐网站包含菜品展示、下订单、在线支付等业务功能模块,该网站的后端系统应用实现了所有这些业务功能。

    而微服务架构则是由一组微服务组成的架构模式。每个微服务都是一个可独立部署的完整系统。一组微服务组成微服务层(注意这里的服务层不同于monolithic架构中的服务层,那个是单系统中的功能模块分层)。微服务层上面一般是应用层,应用层通过组合使用微服务层的各个微服务而向外提供接口(比如HTTP API接口)。各个微服务可以通过RPC接口供应用层调用,比如利用ThriftAvro

 

微服务拆分方法

    微服务架构中的微服务一般按照业务功能来拆分,将关联性较强的业务拆成一个微服务,比如上面订餐网站可以拆分成用户服务、订单服务、菜品服务、支付服务等。具体来说一般根据业务实体名词如订单、用户或者业务动作如登录、下载等来拆分。

 

数据集成 vs. 服务集成

    数据集成是一种比较传统的系统集成方式,其中心是数据。比如交易系统会操作订单表和用户表,比如生成订单。而短信通知系统也会访问订单表和用户表,根据订单的状态来发出不同的短信通知给用户:比如给金额较大的订单对应的用户发一些促销活动短信,给一些未完成订单的用户发短信提醒其完成订单。这就是一种数据集成方式,交易系统和短信通知系统依靠订单表和用户表进行集成。这种集成方式的优点在于实现简单,缺点有下面几条:

l  数据库业务负担较大,因为多个系统都访问同一个数据库的同几张表

l  安全性,交易系统可以修改订单表中的订单状态是理所当然的事,但由于短信通知系统也可以直接访问订单表,可能导致一些意想不到的问题

l  Hbase扩展性问题:交易系统如果以后想把订单表从RDBMS迁到可能就没那么容易了,因为还有很多其他系统也依赖于订单表,真可谓牵一发而动全身;或者各个系统可能擅自做主给表增减字段,都会带来不好后果

l  DAO代码重复,如果交易系统和短信通知系统由两个不同部门的团队开发,那么每个系统中都会有针对订单表和用户表的DAO代码

MySQLRedis    服务集成则打破了数据集成模式,不再以数据为中心集成各系统。微服务架构天然就拥抱服务集成方式。如果用服务集成方式重新设计上面的交易系统和短信通知系统,那么就会提出两个微服务:用户微服务,负责对用户信息进行管理(具体底层是否真的操作关系数据库表,外部已经不关心,即外部不知道用户信息是存在、还是二者都有,也不需要知道);和订单微服务,负责对订单信息进行管理。交易系统和短信通知系统都被提取到更上一层的应用层,他们分别调用用户微服务和订单微服务完成任务。这样用户数据状态的变化和订单数据状态的变化将不再同时受控于交易系统和短信通知系统,而只由用户微服务和订单微服务控制。

 

微服务与微服务之间相互调用

    一般避免微服务直接调用另外一个微服务,尤其忌讳两个微服务相互调用,如果存在两个微服务相互调用的场景,那么得慎重衡量下微服务拆分是否合理。

    当然某些情况无法避免微服务之间相互调用,这时候我们一般可以采用两种方式实现:

l  消息队列

l  消息总线

 

monolithic架构与微服务架构各自优缺点

    除了上面提到的一些优缺点外。下面再总结下两种架构的各自优缺点。

    首先看monolithic架构,它的优点是:部署方便,只需要部署一份代码。但它的缺点有很多:

l  代码庞杂,理解困难,新人上手也困难

l  维护困难,一般一个monolithic架构应用得由一个团队维护,如果应用越大,则维护的人越多,团队管理成本也越高,团队效率也会越低下(3-5人是最佳团队规模)

l  启动一般较慢

l  持续部署困难:每一次小改动都需要重新部署整个应用

l  技术堆栈固化:尝试新技术的代价太高

l  扩展困难:应用某些部分偏IO密集型、某些部分却偏CPU密集型,但应用却只部署在一台机器上,很难用单一硬件来满足应用各部分对硬件资源的不同要求

    微服务架构的优点自然与上面的缺点相反,列举三条:

l  每个微服务功能简单,代码量也不多,新人上手容易

l  每个微服务可以由不同团队开发,每个微服务一般由1-3人开发维护

l  系统稳定性增强,单个服务的失效不会影响其他服务,可以一定程度实现服务降级

l  容易尝试技术创新,甚至每个微服务都可以采用不同的编程语言编写,只要对外提供约定好的接口就行

    但微服务架构也有缺点,按照我个人理解的严重程度由高到低排列如下:

l  运维成本高:原来一个应用一个进程,现在被拆分成微服务后可能有十几个进程,并且每个微服务都需要独立部署

l  测试成本高:微服务架构带来的是一个分布式系统,分布式系统的测试比单系统测试更复杂

l  微服务升级带来的接口不向后兼容问题

l  每个微服务开发者都需要关注微服务开发、集成、测试、部署、上线完整流程

  • 发表于 2017-11-09 10:18
  • 阅读 ( 743 )
  • 分类:Java

你可能感兴趣的文章

相关问题

0 条评论

请先 登录 后评论
不写代码的码农
魏延

IT

5 篇文章

作家榜 »

  1. 威猛的小站长 105 文章
  2. Jonny 65 文章
  3. 江南烟雨 33 文章
  4. - Nightmare 33 文章
  5. doublechina 31 文章
  6. HJ社区-肖峰 29 文章
  7. 伪摄影 20 文章
  8. Alan 14 文章