程序员修神之路–要想做好微服务架构,并非易事!!

点击上方“蓝字”带你去看小星星

菜菜哥,上次听你讲了微服务SOA,明白了很多道理

程序员修神之路--要想做好微服务架构,并非易事!!

看来面试用上了吧

程序员修神之路--要想做好微服务架构,并非易事!!

呵呵,但是面试官问我微服务有什么优点和缺点…

程序员修神之路--要想做好微服务架构,并非易事!!

看来还得给你详细讲一讲微服务

程序员修神之路--要想做好微服务架构,并非易事!!

程序员修神之路--要想做好微服务架构,并非易事!!

概念

程序员修神之路--要想做好微服务架构,并非易事!!

程序员修神之路--要想做好微服务架构,并非易事!!

微服务(Microservices Architecture)是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个微服务代表着一个小的业务能力。

程序员修神之路--要想做好微服务架构,并非易事!!

微服务是根据具体业务领域边界划分出来的能独立运行的程序,并且可以独立部署,可以根据业务量横向扩展,修改不会影响其他程序正常运行。简单一句话:微服务是有一定边界的有自己上下文的服务架构理念。

有点我就给菜菜哥你讲讲吧,看我讲的如何

程序员修神之路--要想做好微服务架构,并非易事!!

好呀,洗耳恭听。

程序员修神之路--要想做好微服务架构,并非易事!!

程序员修神之路--要想做好微服务架构,并非易事!!

微服务优点

程序员修神之路--要想做好微服务架构,并非易事!!

1. 微服务更容易的扩展,它基本上是独立的。应对互联网应用中大并发的系统可以做到自动弹性应对。
2. 每个微服务可以由不同的团队,采用不同的技术栈开发,只要遵循约定的协议即可,每个微服务的修改不会影响到其他服务的正常运行。
3. 微服务的架构思想摒弃了中心化的架构风格,进一步降低了系统间的耦合度,无论是在开发阶段或部署阶段都是独立的。
4. 微服务由于可以快速开发和交付,所以在新技术的接收能力上要远远高于其他系统,例如:将一个传统的系统修改微服务可以快速上,可以快速采用k8s部署。
5. 每个微服务都遵循相同的协议标准,所以再团队之间的沟通上可以减少很多不必要的麻烦。

微服务的优点大体上可以概括为以上几点了

程序员修神之路--要想做好微服务架构,并非易事!!

说的很好啊,但是微服务也有很多缺点,不知道你知不知道

程序员修神之路--要想做好微服务架构,并非易事!!

程序员修神之路--要想做好微服务架构,并非易事!!

微服务缺点

程序员修神之路--要想做好微服务架构,并非易事!!

微服务虽好,但也并非完美。

服务数量

微服务从字面意思就可以知道强调服务的“微”,但是这个微的粒度,多数人都理解错误,有人说:微到不能再微是微服务划分的理念。我不这样认为,微服务的领域边界是根据具体业务来划分,过度的划分,只会导致微服务的数量急剧增加,团队的效率急剧下降。有的团队只有5~6个人,然而却拆分出几十个微服务系统,平均每个人要维护5~10个微服务,这样做给团队带来的只有负面效应。无论是开发,测试,还是运维都需要在多个微服务之间不停的切换。
当微服务上线之后,几十个微服务需要启动几十个进程,在加入了负载均衡与消息中间件后,进程的数量还会持续添加。运维与编排全部这些服务是个“令人望而却步的任务”。
当微服务粒度过细,会造成代码复用度进一步降低,一些通用的代码你可能需要在多个服务间进行copy,如果某段代码有问题,你同时需要修改多个服务代码,当然同种语言可以使用代码共享库来解决,但是在多语言的情况下是行不通的。

事务管理

无论微服务怎么样划分边界,业务上无法避免在多个服务间的事务性操作。最简单的下单场景:很多情况下订单和用户资产是不同的微服务,当用户支付成功,扣除用户资产和更改订单状态(还有减少商品库存)应该是一个原子性操作,如果在以前的单体应用公用一个数据库的情况下,用DB的事务很容易实现原子性操作,但是在微服务环境下,实现事务有一定的难度,尤其是当服务间采用异步操作的时候,这就很复杂了,这要求我们得“管理好相关联的ID以及分布式事务,将各种动作绑定在一起”。

服务关系

服务划分过细,单个服务的复杂度确实下降了,但整个系统的复杂度却上升了,因为微服务将系统内的复杂度转移为系统间的复杂度了。从理论的角度来计算,n 个服务的复杂度是n×(n-1)/2,整体系统的复杂度是随着微服务数量的增加呈指数级增加的。下图形象了说明了整体复杂度:

调用链太长

服务间的通信都采用标准的Http或者Rpc协议,只要是通过网络的调用,就会耗费资源,就会花费更多的执行时间。如果一个请求需要顺序的调用N层服务,那么这个请求所花费的时间是不容忽视的,这在大并发的系统中是致命的性能损耗存在,系统的吞吐量会大幅下降。虽然增加硬件在一定程度上会缓解这种问题,但是却在根本上解决不了问题,而且在成本上会大幅度上升。
另外,服务的调用链太长,定位系统问题很难。一个业务请求会经过N个微服务,任何一个服务有问题,都有可能会导致业务失败。由于调用的微服务过多,而且异常有扩散的属性,快速定位服务问题对于开发以及测试来说,是一件很复杂并且很难的事情。如下图所示:
如果服务C发生故障,开发定位问题的时候需要从服务A开始追踪,然后追踪服务B,然后是服务C,如果调用链更长的话,还需要继续追踪。当定位到问题之后,可能已经过去了几个小时,这在一些敏感的系统中是不允许的。如果服务的复杂性如下图所示,该怎么办呢?
程序员修神之路--要想做好微服务架构,并非易事!!

微服务的架构设计中,做好服务的追踪是很重要的

程序员修神之路--要想做好微服务架构,并非易事!!

自动化支撑

如果没有相应的自动化系统进行支撑,都是靠人工去操作,那么微服务不但达不到快速交付的目的,甚至还不如一个大而全的系统效率高。
当服务的数量到达一定程度,假如如上图所示,服务的治理难度就会被提上日程。当微服务的种类和数量越来越多,如果没有微服务的治理系统去支撑,微服务的优势就会变为劣势,包括每个服务的注册和发现,每个服务的部署,每个服务的隔离,甚至每个服务的路由。
如果还是人工去干预这些,最终服务系统将会变的一片混乱,微服务推重的快速交付,横向扩展等特性也将变的复杂。
程序员修神之路--要想做好微服务架构,并非易事!!

微服务的重点不止在边界的划分,还有服务的治理。就像容器一样,容器很重要,但是容器编排同样重要。

程序员修神之路--要想做好微服务架构,并非易事!!

哎呀,微服务原来有这么多缺点,我再考虑要不要学呢?

程序员修神之路--要想做好微服务架构,并非易事!!

总体来说,在适合微服务的场景下,还是推荐使用微服务架构,在交付过程中,优势还是要大于劣势的

程序员修神之路--要想做好微服务架构,并非易事!!

参考文档:从0开始学架构

程序员修神之路--要想做好微服务架构,并非易事!!

程序员修神之路–为什么我会了SOA,你们还要逼我学微服务?

程序员过关斩将–数据库的乐观和悲观锁并非真实的锁

程序员修神之路–设计一套RPC框架并非易事

程序员过关斩将–要想获取我的用户信息,就得按照规矩来

程序员过关斩将–更加优雅的Token认证方式JWT

程序员过关斩将–cookie和session的关系其实很简单

程序员修神之路–用NOSql给高并发系统加速

程序员修神之路–高并发系统设计负载均衡架构

程序员过关斩将–你为什么还在用存储过程?

● 程序员修神之路–问世间异步为何物?

程序员修神之路–提高网站的吞吐量

关注后回复:“ 大礼包 ”和“ 福利 ”,领取惊喜

长按识别二维码关注

程序员修神之路--要想做好微服务架构,并非易事!!

原文 

http://mp.weixin.qq.com/s?__biz=MzU0Mzk1OTU2Mg==&mid=2247485009&idx=2&sn=4105791e4a32b50bc6de824913f448b8

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

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

转载请注明原文出处:Harries Blog™ » 程序员修神之路–要想做好微服务架构,并非易事!!

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

评论 0

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