进一步了解微服务

周末又看了一个微服务专栏，还是上家公司工程师写的，重实战，理论体系差一点，所以有些地方说不到位，但确实提供了一个完整的概念，本文做个笔记。

微服务本质是为了提升效率：开发效率、协作效率、运维效率。微服务的特点就是拆分力度更细、服务独立部署、独立维护、更高的治理能力。

对于小团队，我觉得能做到服务化也非常不错，而微服务则结合了敏捷开发、持续交付、容器化、DevOps，要求更高。

微服务包含的核心组件：

• 服务描述，就是如何定义和发布你的服务，一般和RPC框架紧密联系。

• 注册中心，由于微服务拆分的非常细，调用者和服务者必须通过发布和订阅的方式互相协作。

• 服务框架，微服务粒度非常细，所以必须有一个RPC框架，定义通信协议、数据传输方式、序列化、服务定义，是不是RPC框架等同于微服务？

  单体应用一般使用短连接，服务请求都在本地，而微服务拆分的太细，必须有更好的网络通信框架，比如开始以为gRPC是跨语言的框架，后来了解到只是客户端支持多语言，说明PHP语言不太合适了。

• 服务治理，为了更好的解决问题，包括监控、敏捷开发等，即使不搞微服务，服务治理也是非常重要的。

学好微服务可能要掌握一个RPC框架，而RPC框架的编程方式和类PHP动态语言机制是非常不同的，需要转变思路，比如并发编程、网络通信框架，线程池，所以Go语言？

微服务核心是RPC框架和异步队列，所以不管什么架构，队列解耦都非常重要，不管搞不搞微服务，队列应该好好琢磨。

对于服务治理来说，如何管理节点，客户端如何进行负载均衡、路由（在单体应用中主要是服务器短控制）、容错，都非常复杂。比如在容错方面，调用失败是常态，所以如何解决呢？调用不了数据库怎么办？单体应用由于业务比较耦合，一个数据库连接实例能服务很多查询，而微服务由于调用之间都是隔离的，情况就更复杂。

有些RPC框架包含了注册中心、服务框架、服务治理，两张图给我印象深刻。

dubbo服务治理图：

dubbo一次完整的调用图：

dubbo这样的RPC框架包含基本的微服务组件，而Spring Cloud全家桶提供服务注册组件、配置中心组件、负载均衡组件、追踪组件，如下图：

从上图看出，不管将来搞不搞微服务，对于监控来说，Zipkin、ELK、Prometheus可以整一整。

微服务是和容器化、DevOps紧密相连的，所以理解它们也很重要。

Docker进程是一个应用级进程，却有自己独立的空间，Docker镜像不光可以打包应用程序本身，还可以打包应用程序的依赖，甚至包含操作系统。有了Docker，就可以保持开发环境、测试环境、线上环境一致性。Docker本质上是分层机制，

容器化后，其本身如何管理呢？它需要发布到镜像仓库中，如何搭建自己的镜像仓库？原理是什么？如何满足高可用和一致性？

镜像要发布到什么机器上呢？这属于资源调度的问题，难点在于如何对接不同的集群，管理集群的权限，如何初始化集群的环境，比如引入Ansible，一致化操作系统和应用环境都非常重要。

服务发布的时候，选择那些机器部署属于容器调度，著名的就是Kubernetes，难点在于如何知道那些机器是存活的，不同集群类型对应的服务器配置， 具体的调度策略是什么。

什么是服务编排呢？

• 微服务之间是有依赖的，这就要求在容器调度的时候，考虑依赖的问题。

• 服务发现，如何让消费者发现服务？

• 扩容缩容

感觉docker、Kubernetes和微服务结合很紧密，但不搞微服务，它们也非常重要，容器化运维平台应该怎么搞？

容器化也要涉及到DevOps了，DevOps的出现也是因为效率的需要，让开发、测试、运维不隔离，合为一体，开发人员不仅要负责业务开发，还要负责测试以及上线发布跟踪等一系列过程，其核心概念就是CI/CD，持续集成、持续部署，主要的技术栈就是GitLab或Jenkins。