Springcloud Alibaba学习

技术作为业务的支撑，永远是伴随着业务发展而发展的，想成为一名优秀的开发者，就要不断地学习新的技术来应对新的问题。

从单体架构到分布式架构的演进
现在看一下，团队中很多项目都有着庞大的架构，看起来都很复杂，也可能经历过好几次重大重构，可能是从最开始的很小的功能演变到现在功能非常丰富的系统。

开始可能因为开发人员少，项目需求紧急，没有运维人员等原因，用了单体架构，随着用户量不断增长，功能越来越多，后端架构面临的挑战就越大，可能从单体架构演变到垂直化和集群，再到SOA，最后到现在的微服务等。这个演变过程可能不一样，都是跟着公司业务走。

单体架构
通常来说，一个war包或者jar包包含一个应用的所有功能，就称之为单体架构。

先用一张简单的商城项目结构图来表示

使用的是Spring+Struts+Hibernate构建的，把所有代码打包成一个war包，部署在Tomcat上。

很多团队早期项目就是差不多这样，架构简单，快速开发上线。

集群和垂直化
随着上面商城系统的用户量也越来越大，网站的访问量不断变大，服务器越来越撑不住，业务场景越来越多，越来越复杂，如果不处理，那服务器随时可能崩溃或者相应很慢。

优化可以从两方面进行：

服务器扩容，遇到性能瓶颈就扩容。
按照业务的垂直领域进行拆分，减少业务耦合度，降低单个war包带来的伸缩性困难问题。

如图，按照业务维度进行了垂直拆分：用户系统，库存系统，商品系统，同时服务器进行了集群部署。

SOA
有两个场景：

下单操作需要先检查商品库存，这个操作是在订单系统里写还是在库存系统里写？整个项目内，类似的代码有很多，开发人员互相也不知道，导致很多冗余的业务代码。
总公司下有很多子公司，每个子公司都有自己的业务和信息，子公司之间信息不共享，形成了信息孤岛。
基于以上问题，引进了SOA，全称是Service-Oriented Architecture，也就是面向服务的架构，核心目标是把一些通用的、会被多次调用的抽离出来提取成独立的服务，这些服务相对比较独立，可以复用。

如图，提取出了用户服务、库存服务、商品服务。

在SOA中，采用ESB来作为系统和服务间通信的桥梁，ESB本身提供服务地址的管理，不同系统之间的各种转化，例如数据格式转化等。

就是调用方不必关心目标服务的位置，和ESB交互就行，实现了调用者和服务提供者的解耦，解决了信息孤岛和冗余代码的问题。

微服务架构
以上被拆出来的服务是否需要以业务功能为维度来拆分呢，降低业务上的耦合。

微服务就是这样的，针对可重用性业务服务进一步优化，随着粒度更细化分，可能1个服务会被拆成10个微服务。

SOA和微服务关注的点不一样：

SOA解决信息孤岛和代码冗余。
微服务关注的事解耦，降低业务之间的耦合度，单个业务模块拆出来一个微服务。

如图，每个业务都被拆成一个微服务，每个服务只关注自己的业务，服务之间通过API网关进行通信。

微服务架构带来的挑战
微服务的优点
各个服务之间耦合度低。
各个微服务都独立部署。
快速响应，修改局部代码不会影响整个系统。
技术选型灵活，可以不同团队维护，自由选择技术栈。
每个微服务都很小，代码容易理解。
可扩展性强，根据每个微服务性能要求来灵活扩展。
容错性好，某个服务故障不会影响整体系统。
微服务的缺点
服务器较多，运维困难，成本高，很麻烦。
一次请求链路较长，故障排查困难。
服务监控比较多，除了单个服务监控，还要在中间链路上进行监控。
网络延迟和网络故障，增加应用复杂度。
服务依赖复杂，A依赖B依赖C，修改的时候要从C-B-A进行修改。
如何实现微服务架构
上面都是微服务的演变过程和优缺点，微服务具体就是如下图的样子。

微服务架构图
在这里插入图片描述

微服务架构下的技术挑战
微服务主要就是实现业务解耦，随着业务不断发展，项目逐渐扩大，微服务组件越来越多，调用关系越来越复杂，那必须考虑失败重试，容错，降级等，就需要服务治理等。

还要考虑，分布式配置中心、服务路由、负载均衡、熔断限流、链路监控等。

这些都是比较大的挑战，后续章节慢慢介绍。