一、认识微服务
下图表示了服务架构从单体应用逐渐转变为微服务应用的过程：
[图片]
1.1 单体架构
很多创业公司早期或者传统企业会把业务的所有功能实现都打包在一个项目，这就是单体架构。业务的所有功能实现都打包在一个 war 包或者 jar 包中，这种方式就称为单体架构。 如果一个项目前端 + 后端 + 数据库实现，都在一个项目中，这种架构就称为单体架构。 以大家都很熟悉的电商系统为例，电商系统包括：用户管理、商品管理、订单管理、支付管理、库存管理、物流管理等，项目早期我们会把这些模块都写在一个 web 项目中，然后统一部署到一个 Web 服务器中。
[图片]
这种架构开发简单，部署简单，一个项目就包含了所有的功能，省去了多个项目之间的交互和调用消耗，直接部署在一个服务器即可。
1.2 集群和分布式架构
当网站的用户量越来越大，需求也会越来越多，流量也会越来越大，服务可能就会面临以下问题：
• 后端服务器的压力就会越来越大，负载越来越高，甚至出现无法访问的情况 • 业务场景逐渐复杂。为了满足用户的需求，单体应用也会越来越大。各个业务代码之间的耦合度也会越来越高。任何一个问题，都需要整个项目重新构建，发布。 • 一个微小的问题，可能会导致整个应用挂掉
我们从两个方面进行优化： • 横向：添加服务器，把单台机器变成多台机器的集群。 • 纵向：把一个应用按照业务进行拆分，拆分为多个项目。此架构也称为垂直架构。
[图片]
以单体结构规模的项目为单位进行垂直划分。也就是将一个大项目拆分成一个个单体结构项目。项目和项目之间相对比较独立，接口多为数据同步功能。
集群和分布式。
• 集群 (cluster) 是将一个系统完整的部署到多个服务器上，每个服务器都能提供系统的所有服务，多个服务器通过负载均衡调度完成任务。每个服务器称为集群的节点 (node) • 分布式是将一个系统拆分为多个子系统，多个子系统部署在多个服务器上，多个服务器上的子系统协同合作完成一个特定任务。
比如： 一个饭店只有一个厨师，这个厨师负责备菜，洗菜，切菜，炒菜。 随着这个饭店的生意越来越好，这个厨师忙不过来了，饭店又请了一个厨师，新厨师和老厨师做一样的事情，也是洗菜，切菜，炒菜。这两个厨师的关系就是集群。 为了让厨师专心炒菜，饭店又请了一个配菜师，负责备菜，洗菜，切菜。厨师和配菜师的关系就是分布式。 后来一个配菜师也忙不过来了，又请了一个配菜师，这两个配菜师的关系就是集群。
[图片]
集群和分布式区别和联系：
从概念上。集群是多个计算机做同样的事，分布式是多个计算机做不同的事 2. 从功能上。集群的每一个节点功能是相同的，并且可以替代的。分布式也是多个节点组成的系统，但是每个节点完成的业务是不同的，一个节点出现问题，这个业务就不可访问了。 3. 从关系上。分布式和集群在实践中，很多时候是互相配合使用的。比如分布式的某一个节点，可能由一个集群来代替。分布式架构大多是建立在集群上的。所以实际的分布式架构设计中并不会把分布式和集群单独区分，而是统称：分布式架构
1.3 微服务架构
从上图中可以看出，按照业务进行拆分后，会有一些重复的功能开发，比如订单系统，电商平台和支付系统都会涉及。 在分布式架构下，当部署的服务越来越多，重复的代码就会越来越多，服务的调用关系也会越来越复杂。我们可以把一些通用的，会被多个上层服务调用的共享业务，提取成独立的基础服务，组成一个个微小的服务。这就是微服务。
[图片]
简单来说，微服务就是很小的服务。小到⼀个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，微服务之间可以采用 REST 和 RPC 协议进行通信。 REST 和 RPC 后面我会为大家介绍，此处把他理解为接口的约定。 从这个角度来看，微服务架构是分布式架构的一种拓展，这种架构模式下它拆分粒度更小，服务更独立。可以理解为：微服务是一种经过良好架构设计的分布式架构方案。
分布式架构&微服务架构 分布式：服务拆分，拆了就行。 微服务：指非常微小的服务，更细粒度的垂直拆分，通常指不能再拆的服务。
分布式架构侧重于压力的分散，强调的是服务的分散化。微服务侧重于能力的分散，更强调服务的专业化和精细分工。从实践的角度来看，微服务架构通常是分布式服务架构，反之则未必成立。所以，选择微服务通常意味着需要解决分布式架构的各种难题。
1.4 微服务带来的挑战
随着产品的复杂性和流量的增加，技术架构也在不断的发生变化。不论是早期的单体架构，还是现在广泛使用的微服务架构，都是为了更好的服务产品，解决问题。 微服务架构带来好处的同时，也面临着一些挑战，从单体服务转向微服务意味着管理更加复杂。接下来我们从优势和挑战两个方面分析一下微服务架构。
优势：
• 易开发和维护。每个微服务负责的业务比较清晰，体量小，开发和维护成本降低。 • 容错性高。一个服务发生故障，可以使故障隔离在单个服务中，不影响整体服务故障。 • 扩展性好。每个服务都是独立运行的，我们可以结合项目实际情况进行扩展，按需伸缩。 • 技术选型灵活。每个微服务都是单独的团队来运维，可以根据业务特点和团队特点，选择适合的技术栈
