SpingCloud Alibaba实战（1：微服务与SpringCloud Alibaba）

一、什么是微服务？

微服务可谓是这几年比较热门的技术，从2017开始逐渐爆火，逐渐大大小小的公司纷纷将微服务技术引入并在实际业务中落地。

微服务的概念最先是在2014年由Martin Fowler和James Lewis共同提出：微服务是由单一应用程序构成的小服务，拥有本身的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其余服务使用HTTP API通信。同时，服务会使用最小规模的集中管理 （例如Docker）技术，服务能够用不一样的编程语言与数据库等。

1.一、单体应用之痛

为何要用微服务？微服务真的那么好吗？

在认识这些以前，得了解单体架构的弊端。

以MVC架构为例，业务一般是经过部署一个WAR包到Tomcat中，而后启动Tomcat，监听某个端口便可对外提供服务。早期在业务规模不大、开发团队人员规模较小的时候，采用单体应用架构，团队的开发和运维成本均可控。

然而随着业务规模的不断扩大，团队开发人员的不断扩张，单体应用架构就会开始出现问题。大体有如下几个方面：

• 部署效率低下
• 团队协做开发成本高
• 系统高可用性差
• 线上发布变慢

1.二、面向服务（SOA）

面向服务就是把传统的单机应用中经过JAR包依赖产生的本地方法调用，改形成经过RPC接口产生的远程方法调用。

1.三、微服务

微服务能够理解为面向服务的进一步发展。

在SOA的基础上，微服务主要有了如下的发展：

• 服务拆分粒度更细。微服务能够说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其余模块都没有关系，那么就能够拆分为一个微服务。
• 服务独立部署。每一个微服务都严格遵循独立打包部署的准则，互不影响。好比一台物理机上能够部署多个Docker实例，每一个Docker实例能够部署一个微服务的代码。
• 服务独立维护。每一个微服务均可以交由一个小团队甚至我的来开发、测试、发布和运维，并对整个生命周期负责。
• 服务治理能力要求高。由于拆分为微服务以后，服务的数量变多，所以须要有统一的服务治理平台，来对各个服务进行管理。

总结来讲，微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分，每一个拆分出来的服务各自独立打包部署，并交由小团队进行开发和运维，从而极大地提升了应用交付的效率，并被各大互联网公司所广泛采用。

这里附上一张架构演进简略示意图：

二、微服务如何拆分

2.一、微服务拆分的两种方式

微服务拆分具体该如何实施呢？

一个最有效的手段就是将不一样的功能模块服务化，独立部署和运维。以社交App为例，能够认为首页信息流是一个服务，评论是一个服务，消息通知是一个服务，我的主页也是一个服务。

这种服务化拆分方式是纵向拆分，是从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。

还有一种服务化拆分方式是横向拆分，是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其余服务调用，且依赖的资源独立不与其余业务耦合。

仍然社交App举例，不管是首页信息流、评论、消息箱仍是我的主页，都须要显示用户的昵称。假如用户的昵称功能有产品需求的变动，你须要上线几乎全部的服务，这个成本就有点高了。显而易见，若是我把用户的昵称功能单独部署成一个独立的服务，那么有什么变动我只须要上线这个服务便可，其余服务不受影响，开发和上线成本就大大下降了。

2.二、微服务拆分须要解决的问题

必需要认识到，微服务架构也是有成本的，架构复杂度提高，也会带来一些新的问题，这些微服务架构必需要解决的问题：

• 服务如何定义。对于单体应用来讲，不一样功能模块以前相互交互时，一般是以类库的方式来提供各个模块的功能。对于微服务来讲，每一个服务都运行在各自的进程之中，应该以何种形式向外界传达本身的信息呢？答案就是接口，不管采用哪一种通信协议，是HTTP仍是RPC，服务之间的调用都经过接口描述来约定，约定内容包括接口名、接口参数以及接口返回值。
• 服务如何发布和订阅。单体应用因为部署在同一个WAR包里，接口之间的调用属于进程内的调用。而拆分为微服务独立部署后，服务提供者该如何对外暴露本身的地址，服务调用者该如何查询所须要调用的服务的地址呢？这个时候你就须要一个相似登记处的地方，可以记录每一个服务提供者的地址以供服务调用者查询，在微服务架构里，这个地方就是注册中心。
• 服务如何监控。一般对于一个服务，咱们最关心的是QPS（调用量）、AvgTime（平均耗时）以及P999（99.9%的请求性能在多少毫秒之内）这些指标。这时候你就须要一种通用的监控方案，可以覆盖业务埋点、数据收集、数据处理，最后到数据展现的全链路功能。
• 服务如何治理。能够想象，拆分为微服务架构后，服务的数量变多了，依赖关系也变复杂了。好比一个服务的性能有问题时，依赖的服务都势必会受到影响。能够设定一个调用性能阈值，若是一段时间内一直超过这个值，那么依赖服务的调用能够直接返回，这就是熔断，也是服务治理最经常使用的手段之一。
• 故障如何定位。在单体应用拆分为微服务以后，一次用户调用可能依赖多个服务，每一个服务又部署在不一样的节点上，若是用户调用出现问题，你须要有一种解决方案可以将一次用户请求进行标记，并在多个依赖的服务系统中继续传递，以便串联全部路径，从而进行故障定位。

三、微服务技术选型

对于大部分公司而言，自研来解决微服务架构的一些问题，成本是很难接受的。不过，幸运的是，有很多业界开源方案可供选择。

前几年比较火的是阿里的Dubbo，后来一度中止维护，最近两年又起死回生，从新焕发生机。

后来又出现了Spring体系下的微服务方案Spring Cloud，并迅速流行起来。

Spring Cloud自己不是新的框架，它是一系列框架的有机组合，利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发。并不是全部组件都由Spring提供，Netflix扮演了重要的角色。

注册中心Eureka、熔断器Hystrix、负载均衡组件Ribbon、网关Zuul等重要组件均由Netflix提供。

四、为何要使用SpringCloud Alibaba

SpringCloud生态已经如此完善了。什么是SpringClou Alibaba? 为何要使用SpringCloud Alibaba?

来自阿里云的说法：

Spring Cloud 自己是一套微服务规范，并非一个拿来便可用的框架，而 Spring Cloud Alibaba 的开源为开发者们提供了这套规范的实现方式。同时，Spring Cloud Alibaba 提供的完整的微服务组件、中文文档和本地化的开源服务提升了开发者们接入微服务的速率，并下降了后续的运维难度。

简单说，Spring Cloud Alibaba是阿里开源的一套Sping Cloud规范的实现。

那么，第二点，为何要使用SpringCloud Alibaba？

由于上面提到的SpringCloud官方版，或者说SpringCloud Netflix版一些重要组件如注册中心Euraka、Ribbon已经再也不迭代更新了。

SpringCloud Alibaba恰逢其会开源孵化毕业，因此这两年热度迅速提高，甚至能够说是"SpringCloud2.0"。

来自阿里SpringCloud Alibaba整体结构图：

和SpringCloud Netflix的主要区别：

Spring Cloud Alibaba 各版本兼容表:

好了微服务和SpringCloub Alibaba的简介到此结束！

---

参考

【1】：小专栏：SpringCloudAlibaba微服务实战

【2】：Java日知录 SpringCloud Alibaba微服务实战

【3】：极客时间 从0开始学微服务 微博服务化专家的一线实战经验

【4】：微服务技术选型之路

【5】：Spring 社区的惟一一个国产开源项目 - Spring Cloud Alibaba 毕业了