微服务经验分享&杂谈

一个应用,拆分为多个小服务,这样的架构方式,就是微服务架构

微服务核心要素

微服务经验分享&杂谈

微服务架构实例

我们拿一个电商贷款场景(如京东白条)划分微服务举例,以便后面的描述。 购买场景主要有如下关键服务。

  • 账户服务:负责管理用户基本信息,如姓名,性别,身份证等
  • 额度服务:用户所能使用的额度。
  • 支付服务:负责完成支付操作。
  • 账单服务:指定时间生成账单给用户。
  • 风控服务:通过数据分析,管理用户操作权限。

我们一开始设计出如下图的服务架构:

微服务经验分享&杂谈

对比的微服务的标准: 符合单独部署; 符合进程独立; 服务间通信使用rpc,符合轻量级。

专注于一件事这一点,看起来是符合,但是我们结合两个实际流程:

支付流程:

微服务经验分享&杂谈

注册流程:

微服务经验分享&杂谈

我们可以看到,除了微服务本身的逻辑,在具体流程下,部分微服务还要考虑如何和别的服务串起来,也就是说,原有的逻辑层,并未消失,而是分散到了各个微服务,职责并不单一!

于是架构进化:

微服务经验分享&杂谈

可以看到,多了一层聚合层。专门负责聚合领域层的数据,对外提供接口。而领域层的微服务,只用承担好自己领域的职责,提供出独立,通用的服务接口。但在业务扩展的过程中,我们发现聚合层业务越来越重,于是乎,我们需要继续演进:

微服务经验分享&杂谈

聚合层也做了拆分,于是,领域层是一组微服务,聚合层是一组微服务,职责清晰。聚合层划分通常可以考虑到实际业务的前端界面,页面为最小粒度来考虑聚合层微服务,不失为一个参考办法,即一个页面或者几个页面为一个微服务。

微服务的优势与劣势

五年前加入腾讯时还是使用典型的logic-server架构,后面微服务如燎原之火,成了新的主角。后续经历的上市外企,tmd中的一家,微服务也是大行其道。也时常思考微服务的必要性。

微服务 优点:

  1. 模块小而独立,方便新人上手;
  2. 发布时候,只发布对应的微服务,减少依赖和查错成本。
  3. 由于拆分得比较细,重构时不容易背太大的技术债务。
  4. 新的微服务中,可以大胆使用新技术,不受原有模块的制约。

缺点

  1. 容易只关注自己一亩三分地,对整体把握不足。
  2. 微服务真正的难点在于划分,如果划分不当,那么服务存在耦合,比如一些状态信息,是服务b管理,但是服务a又十分需要,此时无论是通知还是轮询,都是很麻烦的事。
  3. 一个完整数据,可能需要从多个服务反复获取,如果存在层级关系,可能一个请求就导致几十个rpc。
  4. 后台开发中每个其他服务都是不可信的,都需要做错误处理,那此时聚合层如果调用5个领域服务成功,一个领域失败,抛出错误还是降级服务,也是个让人得具体思考的问题。

原文 

https://juejin.im/post/5d609576f265da03bc1282a5

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 微服务经验分享&杂谈

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址