关于微服务的二三事

最近，由于一些原因在疯狂的恶补关于微服务架构的一些东西，虽然有很多东西还是不太清楚，不过对于微服务的核心和相关价值也算是有了一定的了解，现在将一些有趣的点记录下来，供给希望了解微服务的同学做一些参考。

聊到微服务，我们第一个需要讲到的是SOA，之前我也写过一片关于单体架构和SOA的一些东西，有兴趣的同学可以去这里找找看。Link

简单来说，微服务是一个架构的概念，它的核心思路是拆分，通过把完整项目做微服务化来实现松耦合的目标。比较典型的演进方向如下

微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，真正地实现服务自治。而将SOA的思想进入到单个业务系统内部，实现真正的组件化。

当然把一个application拆分成一些更小的模组块是需要进行业务改造的，而且越成熟的企业业务改造的内容也会越复杂。但是这些改造对于企业架构来说是必要的，微服务可以极大的提升整体系统的稳定性，实现服务自治，而且可以按业务组织团队，将整体架构模型收缩到最小，也可以让每块组件的复用率更高。打个最简单的例子，比如一个电商秒杀活动，以前单体架构的感受是:高峰期人多的时候，页面刷不开，等刷开的时候，东西都被都抢光了。给人体验非常不好。为了提高体验，对单体架构进行扩容提升性能，只能购买昂贵的服务器，去支撑峰值流量，而绝大部分人都是在访问页面，后面的选择、(加入购物车)、下单、支付、每个环节的转换率都会使访问量降低，而单体架构的扩容是对所有功能进行整体扩容，造成大量浪费，如果采用微服务架构以后，可以针对浏览界面的服务做更多扩容，订单服务少量扩容，不再需要对所有功能进行整体扩容，所以把功能拆分微服务后，既能提升用户体验，又能实现节约硬件成本的作用。当然由于采用微服务，他的访问页面，下单，支付模块都是独立的，比如我现在要做另一个项目需要支付模块，其实完全可以复用。

去中心化的自治和去中心化的数据管理也可以让各个组件能针对不同的业务特点选择不同的技术平台。

那么我们来总结下刚刚所说的几点，首先微服务其实是对原有的单体架构，SOA架构做了进一步的拆分，让SOA的概念融入到每个企业组件，来实现松耦合，服务自治，动态扩容，节约成本的目的，最小颗粒度的概念也可以让组件的复用率更高。但是与之带来的是复杂的服务治理，服务调用，与去中心化带来的服务数据同步，异常排障困难等等等问题，也是微服务不得不面对的。我觉得这些问题的解决，应该就是腾讯云TSF平台最关键的价值把。

下面，我们脚踏实地来看看现有的微服务生态把：

1.Spring Cloud微服务架构

Spring Cloud是基于Spring Boot的微服务的框架,只能采用Java语言。
Spring Cloud是一个包含很多子项目的整体方案，其中由Netflix开发又并入的Spring Cloud Netflix 是Spring Cloud微服务架构的核心项目。

2.ZeroC IceGrid微服务架构

ZeroC IceGrid是基于RPC框架发展而来的一种微服务架构，具有良好的性能与分布式能力。

3.基于消息队列的微服务架构

除了基于RPC通信(包括类RPC的通信如Http Rest、SOAP等)的微服务架构，还有基于消息队列通信的微服务架构，这种架构下的微服务采用发送消息(Publish Message)与监听消息(Subscribe Message)的方式来实现彼此之间的交互。

目前比较流行的应该就是Spring boot + Spring Cloud的这一套微服务解决方案了。如果学过Java的同学，对于这一套应该不是很陌生。那我们下面就来讲讲Springcloud。

Spring Cloud是基于Spring Boot实现微服务的框架，包含多个子项目的整体方案包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等。

Spring boot 是 Spring 的一套快速配置脚手架，可以基于spring boot 快速开发单个微服务; Spring Cloud是一个基于Spring Boot实现的云应用开发工具。

所以Spring boot其实是springcloud的前提。

这时，有的小伙伴可能就会问了，那么springcloud的组件是怎样的啊？别着急，我们先来看看它的大体架构把：

Netflix 公司提供了包括Eureka、Hystrix、Zuul、 Archaius等在内的很多组件，在微服务架构中至关重要，Spring在Netflix 的基础上，封装了一 系列的组件，命名为:Spring Cloud Eureka、Spring Cloud Hystrix、Spring Cloud Zuul等。 更多介绍

介绍完Springcloud，我们来看看什么是服务网格(Service Mesh)

根据Linkerd CEO William Morgan定义，Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。

Service Mesh 通常是由一系列轻量级的网络代理组成的，如上图中的蓝色块就是网络代理(这个网络代理也被称之为Sidecar)，深绿色块就是我们的应用。各个微服务应用之间的通信都被网络 代理劫持，相当于在服务之间加了一个中间层，应用之间要想通信，必须要通过这个中间层;这 个网络代理与应用程序部署在一起，但是相对于应用程序来说它是完全不需要知道有这个网络代 理的。

Sidecar模式是一种将应用功能从应用本身剥离出来作为单独进程的方式。该模式允许我们应用无侵入添加多种功能，避免了为满足第三方组件需求而向应用添加额外的配置代码。

总的来说Service Mesh主要解决的是SpringCloud对异构语言兼容，让开发者可以无需重构去兼容一些非SpringBoot的一些语言。

典型的场景如下：

这些，应该就是微服务的基础了，当然除了SpringCloud，我们还有很多基于RPC的框架，比如腾讯的TARS，更多的内容我总结了一个xmind，感兴趣的同学可以研究下：

本人水平有限，如有错误，还请各位大佬指正  -v-