谈谈对微服务的理解(PHP面试理论题)
目录
- 一、什么是微服务架构？
- 二、出现原因
- 三、体系
- 四、微服务架构的优点
- 五、微服务的缺点
- 六、学习路线
简介
参考的学习链接
- 微服务设计
- 云原生分布式存储基石：etcd深入解析
- Docker技术入门与实战
- 每天5分钟玩转Kubernetes
- 左耳听风
- 从0开始学微服务
一、什么是微服务架构？
微服务是一种架构概念，旨在通过将功能分解到各个离散的服务中已实现对解决的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多 SOLID 原则。微服务架构是一个很有趣的概念，它的主要作用是将功能分解到离散的各个服务中，从而降低系统的耦合性，并提供更加灵活的服务支持。
概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
定义：围绕业务领域组件来创建应用，这些应用可以独立的进行开发，管理，和迭代。在分散的组件中使用云架构和平台式部署，管理和服务功能。使产品交付变得更加简单。
本质：用一些功能比较明确，业务比较精炼的服务区解决更大，更实际的问题
二、出现原因
微服务为什么会出现？我觉得这是互联网发展的必然结果。
如同以前没有IOS七层模型的时候，当时的程序员做编程，他们需要自己做七层模型做的事情，这个事情每一个程序员都需要做，造成了大量的资源浪费，而且每个人做出的效果也很难说完美。然后IOS七层模型出现了，统一的规范帮程序员完成重复性工作，大大提升了开发效率。
这么看来的话，微服务做的是相同的事情。
互联网历经几十年的发展，头部公司规模巨大，碰到大量问题，而这些问题每一个企业都可能遇到。在很多事情上大家都在重复造轮子，而且很多时候做的也未必很好。高人们在吸收优秀实践的基础上，结合自己广博的学识，推动了微服务的发展。
目前看微服务形成统一标准还比较困难，一是从整个发展阶段来看，现在还是处于初期，相关的微服务人才并没有大量出现，二是各个公司自身业务情况不一样，很难完全统一。但是，微服务其实已经成燎原之势，在不久的将来，可能开一家互联网公司会变得更加简单，微服务会像TCP/IP一样，对开发人员来说是完全透明的，开发人员只需要关注开发业务逻辑即可，当然，前提是发展到这个阶段，还需要程序员的话。
开发这种通用性的微服务平台，倒也是很不错的一个创业方向。
所以作为当代程序员，学习微服务还是必须的，这是必然的趋势，也能增加自己的竞争力。假如真有一天，微服务和TCP/IP一样透明了，懂微服务核心原理的人仍然更有价值，毕竟到时候只有这些人才能解决某些神奇的问题。
三、体系
微服务的水挺深的，准确的说，不仅深还特别广。微服务涉及的内容特别多，而且每一块都可以深入研究，成为这方面的专家。
在《微服务设计》这本书里，给微服务下的定义为：微服务就是一些协同工作的小而自治的服务。
这个定义不是特别好，总感觉是把微服务的范围缩小了。
另外阅历不同对这句话的理解上差距还是蛮大的。记得以前我有一个评论系统，评论服务、评论后台、DB、缓存等都是独立部署的，我当时觉得这个评论系统就是微服务。这么说不能算百分之百的错，但肯定也不是正确的。
因为微服务阐述的是一整套体系，单单一个独立的服务，只占微服务很小的一部分。
微服务主要由6部分构成
- 服务描述
类似服务的说明文档，简单但不可或缺。比如，服务调用首先要解决的问题就是服务如何对外描述。比如，你对外提供了一个服务，那么这个服务的服务名叫什么？调用这个服务需要提供哪些信息？调用这个服务返回的结果是什么格式的？该如何解析？这些就是服务描述要解决的问题。
- 注册中心
有了服务的接口描述，下一步要解决的问题就是服务的发布和订阅，就是说你提供了一个服务(Provider)，如何让外部(Consumer)想调用你的服务的人知道。这个时候就需要一个类似注册中心(Registry)的角色，服务提供者将自己提供的服务以及地址登记到注册中心，服务消费者则从注册中心查询所需要调用的服务的地址，然后发起请求。
- 服务框架
通过注册中心，服务消费者就可以获取到服务提供者的地址，有了地址后就可以发起调用。但在发起调用之前你还需要解决以下几个问题。服务通信采用什么协议？是RESTful API还是gRPC？数据传输采用什么方式数据压缩采用什么格式？这些活通常集成到了我们的服务框架里面，市面上有很多这样的开源框架，相对都比较成熟，接下来考验你的是快速上手的能力。
- 服务监控
一旦服务消费者与服务提供者之间能够正常发起服务调用，你就需要对调用情况进行监控，以了解服务是否正常。通常来讲，服务监控主要包括三个流程，指标收集，数据处理，数据展示。监控是为了发现问题和异常，如果要进一步跟踪和定位问题，则需要进一步了解服务追踪。
- 服务追踪
除了需要对服务调用情况进行监控之外，你还需要记录服务调用经过的每一层链路，以便进行问题追踪和故障定位，最后达到接近问题的目的。服务监控和追踪可以合并起来，但是要明确各自的职责是不一样的。
- 服务治理
服务监控能够发现问题，服务追踪能够定位问题所在，而解决问题就得靠服务治理了。服务治理就是通过一系列的手段来保证在各种意外情况下，服务调用仍然能够正常进行。就目前开源的服务框架，大部分都不包括服务治理的内容，所以有可能这块是需要你和你的团队进行定制化开发，就看你做到什么程度了，就好比你有数据库但是你没有ER图描述，并不影响你用微服务，当然如果有就是锦上添花的东西了。
这6部分组合起来才称之为微服务。下面的链接是我做的一个思维导图，导图里面的有些内容我还没有完全学会，后期会做进一步的整理，如果大家喜欢的话，可以先记一下这个链接。
https://www.processon.com/view/link/5f3952a17d9c0806d41a90a9
四、微服务架构的优点
有效的拆分应用，实现敏捷开发和部署
分工不同，以前我们可能是一人一个模块，现在可能是一人一个系统
架构不同，服务的拆分是一个技术含量很高的问题，拆分是否合理对以后发展影响巨大
部署方式不同，如果还像以前一样部署估计累死了，自动化运维不可不上
容灾不同，好的微服务可以隔离故障避免服务整体垮掉，坏的微服务设计仍然可以因为一个子服务出现问题导致连锁反应
扩展不同，微服务更容易按需求进行横向和纵向扩展
微服务做的事情是按照项目颗粒度进行服务的拆分，把模块单独拿出来做成每一个单独的小项目。微服务的主要特点有：
每一个功能模块是一个小项目，独立运行在不同进程或者机器上，不同功能可以由不同的人员开发独立开发，独立部署不需要依赖整体项目就可以启动单个服务，分布式管理，每个服务做好自己的事情就好，设计微服务时需要考虑数据库，是所有服务公用一个数据库还是一个服务一个数据库。
五、微服务的缺点
因为微服务架构的复杂度，对技术要求高，所以要考虑团队是否已经具备相关技术
公司业务是否适合进行微服务改造，并不是都一定适合，传统行业有很多复杂的垂直的业务架构。
微服务生态的技术又很多，并不是每一个技术方案都需要用上，适合自己的才是最好的
对于微服务架构：技术上不是问题，意识比工具重要！
什么是 RPC？
很多传统的 phper 并不懂什么是 rpc，RPC 全称 Remote Procedure Call, 中文译为远程过程调用，其实你可以把它理解为一种架构性上的设计，或者是一种解决方案。
通过 RPC 我们可以像调用本地方法一样调用别的机器上的方法，用户将无感服务器之间的通讯，RPC 在微服务中起到了相当大的作用
六、学习路线
微服务算是集现代互联网技术大成者。我是初学者，需要给自己建立一条学习路线，这样能够帮助自己更好的掌握内容。
对于学习路线，我认为有几个原则：
找出必学内容并做笔记
以前看过很多文章或者书籍，但是没有把内容写下来，总觉得学得比较浅，将内容消化后写出来，能够加深印象
必学的内容应该是核心内容，像k8s、docker、分布式等是百分之百需要学习的
不必学
同一个方案有多个技术选型，只学一个就行。如服务编排只要看k8s，因为这个已经算是行业标准。服务追踪可以从zipkin和skywalking中选择一个
有些内容特别偏向于运维层面，可以了解浅一点或者完全不去了解
不断更新和丰富脑图
学习过程中，需要进行实践，最终搭建出基础款微服务。
目前计划学习以及重新学习的内容有
- k8s
- docker
- Etcd
- GRPC
- Netty
- Dubbo
- ELK
- Grafana
- Kafka
- Skywalking
- Apollo
- Istio
其实除了这些，微服务还有很多其他的内容需要学习，这些内容可以在今后慢慢补齐。