浅谈微服务

144 阅读8分钟

简介

微服务兴起已经多年了,这几年已到大发展阶段。公司内部做了很多和微服务相关的事情,自己也看了一些微服务相关的内容。现在再来认识”微服务“三个字,终于有点懂了的感觉。

学习期间看过的内容有

  1. 微服务设计
  2. 云原生分布式存储基石:etcd深入解析
  3. Docker技术入门与实战
  4. 每天5分钟玩转Kubernetes
  5. 左耳听风
  6. 从0开始学微服务

出现原因

微服务为什么会出现?我觉得这是互联网发展的必然结果。

如同以前没有IOS七层模型的时候,当时的程序员做编程,他们需要自己做七层模型做的事情,这个事情每一个程序员都需要做,造成了大量的资源浪费,而且每个人做出的效果也很难说完美。然后IOS七层模型出现了,统一的规范帮程序员完成重复性工作,大大提升了开发效率。

这么看来的话,微服务做的是相同的事情。

互联网历经几十年的发展,头部公司规模巨大,碰到大量问题,而这些问题每一个企业都可能遇到。在很多事情上大家都在重复造轮子,而且很多时候做的也未必很好。高人们在吸收优秀实践的基础上,结合自己广博的学识,推动了微服务的发展。

目前看微服务形成统一标准还比较困难,一是从整个发展阶段来看,现在还是处于初期,相关的微服务人才并没有大量出现,二是各个公司自身业务情况不一样,很难完全统一。但是,微服务其实已经成燎原之势,在不久的将来,可能开一家互联网公司会变得更加简单,微服务会像TCP/IP一样,对开发人员来说是完全透明的,开发人员只需要关注开发业务逻辑即可,当然,前提是发展到这个阶段,还需要程序员的话。

开发这种通用性的微服务平台,倒也是很不错的一个创业方向。

所以作为当代程序员,学习微服务还是必须的,这是必然的趋势,也能增加自己的竞争力。假如真有一天,微服务和TCP/IP一样透明了,懂微服务核心原理的人仍然更有价值,毕竟到时候只有这些人才能解决某些神奇的问题。

体系

微服务的水挺深的,准确的说,不仅深还特别广。微服务涉及的内容特别多,而且每一块都可以深入研究,成为这方面的专家。

在《微服务设计》这本书里,给微服务下的定义为:微服务就是一些协同工作的小而自治的服务。

这个定义不是特别好,总感觉是把微服务的范围缩小了。

另外阅历不同对这句话的理解上差距还是蛮大的。记得以前我有一个评论系统,评论服务、评论后台、DB、缓存等都是独立部署的,我当时觉得这个评论系统就是微服务。这么说不能算百分之百的错,但肯定也不是正确的。

因为微服务阐述的是一整套体系,单单一个独立的服务,只占微服务很小的一部分。

微服务主要由6部分构成

  1. 服务描述

    类似服务的说明文档,简单但不可或缺。比如,服务调用首先要解决的问题就是服务如何对外描述。比如,你对外提供了一个服务,那么这个服务的服务名叫什么?调用这个服务需要提供哪些信息?调用这个服务返回的结果是什么格式的?该如何解析?这些就是服务描述要解决的问题。

  2. 注册中心

    有了服务的接口描述,下一步要解决的问题就是服务的发布和订阅,就是说你提供了一个服务(Provider),如何让外部(Consumer)想调用你的服务的人知道。这个时候就需要一个类似注册中心(Registry)的角色,服务提供者将自己提供的服务以及地址登记到注册中心,服务消费者则从注册中心查询所需要调用的服务的地址,然后发起请求。

  3. 服务框架

    通过注册中心,服务消费者就可以获取到服务提供者的地址,有了地址后就可以发起调用。但在发起调用之前你还需要解决以下几个问题。服务通信采用什么协议?是RESTful API还是gRPC?数据传输采用什么方式数据压缩采用什么格式?这些活通常集成到了我们的服务框架里面,市面上有很多这样的开源框架,相对都比较成熟,接下来考验你的是快速上手的能力。

  4. 服务监控

    一旦服务消费者与服务提供者之间能够正常发起服务调用,你就需要对调用情况进行监控,以了解服务是否正常。通常来讲,服务监控主要包括三个流程,指标收集,数据处理,数据展示。监控是为了发现问题和异常,如果要进一步跟踪和定位问题,则需要进一步了解服务追踪。

  5. 服务追踪

    除了需要对服务调用情况进行监控之外,你还需要记录服务调用经过的每一层链路,以便进行问题追踪和故障定位,最后达到接近问题的目的。服务监控和追踪可以合并起来,但是要明确各自的职责是不一样的。

  6. 服务治理

    服务监控能够发现问题,服务追踪能够定位问题所在,而解决问题就得靠服务治理了。服务治理就是通过一系列的手段来保证在各种意外情况下,服务调用仍然能够正常进行。就目前开源的服务框架,大部分都不包括服务治理的内容,所以有可能这块是需要你和你的团队进行定制化开发,就看你做到什么程度了,就好比你有数据库但是你没有ER图描述,并不影响你用微服务,当然如果有就是锦上添花的东西了。

这6部分组合起来才称之为微服务。下面的链接是我做的一个思维导图,导图里面的有些内容我还没有完全学会,后期会做进一步的整理,如果大家喜欢的话,可以先记一下这个链接。

www.processon.com/view/link/5…

学习路线

微服务算是集现代互联网技术大成者。我是初学者,需要给自己建立一条学习路线,这样能够帮助自己更好的掌握内容。

对于学习路线,我认为有几个原则:

  1. 找出必学内容并做笔记
    • 以前看过很多文章或者书籍,但是没有把内容写下来,总觉得学得比较浅,将内容消化后写出来,能够加深印象
    • 必学的内容应该是核心内容,像k8s、docker、分布式等是百分之百需要学习的
  2. 不必学
    • 同一个方案有多个技术选型,只学一个就行。如服务编排只要看k8s,因为这个已经算是行业标准。服务追踪可以从zipkin和skywalking中选择一个
    • 有些内容特别偏向于运维层面,可以了解浅一点或者完全不去了解
  3. 不断更新和丰富脑图
  4. 学习过程中,需要进行实践,最终搭建出基础款微服务。

目前计划学习以及重新学习的内容有

  1. k8s
  2. docker
  3. Etcd
  4. GRPC
  5. Netty
  6. Dubbo
  7. ELK
  8. Grafana
  9. Kafka
  10. Skywalking
  11. Apollo
  12. Istio

其实除了这些,微服务还有很多其他的内容需要学习,这些内容可以在今后慢慢补齐。

资料

  1. 微服务学习架构路线图(初稿)

  2. 微服务学习导航

  3. 【干货分享】可能是东半球最全的.NET Core跨平台微服务学习资源

最后

大家如果喜欢我的文章,可以关注我的公众号(程序员麻辣烫)

往期文章回顾:

技术

  1. 浅谈微服务
  2. TCP性能优化
  3. 限流实现1
  4. Redis实现分布式锁
  5. Golang源码BUG追查
  6. 事务原子性、一致性、持久性的实现原理
  7. CDN请求过程详解
  8. 记博客服务被压垮的历程
  9. 常用缓存技巧
  10. 如何高效对接第三方支付
  11. Gin框架简洁版
  12. InnoDB锁与事务简析

读书笔记

  1. 如何锻炼自己的记忆力
  2. 简单的逻辑学-读后感
  3. 热风-读后感
  4. 论语-读后感

思考

  1. 对项目管理的一些看法
  2. 对产品经理的一些思考
  3. 关于程序员职业发展的思考
  4. 关于代码review的思考
  5. Markdown编辑器推荐-typora