微服务基础
单体架构
通常来说 ，如果一个war包或者jar包中包含一个应用的所有功能，则我们称这种架构模式为单体架构。
很多创业型的公司和传统的互联网公司早期基本都会采用这样的架构，原因是这样的架构足够简单，能够快速的开发和上线，并且对于初期用户量不大的情况，这种架构是足以支撑业务的正常运行的。
集群和垂直化
当业务场景越来越多，模块功能越来越多，这就意味着war包或者jar包中的代码量会持续上升，并且各个模块的耦合度也会越来越高，这样后期的维护和上线就会存在较大的问题，这个时候就需要进行一些优化。
- 通过横向扩充服务器，如使用Nginx来做一些负载均衡，使单机变为多机集群。
- 按照业务的垂直领域进行服务的拆分，减少业务的耦合度。
- 分库分表，对数据库进行垂直拆分，对热字段冷字段进行冷热分离。
总体来说，数据库层面和系统业务的拆分思想都是一样的，都是采用分而治之的思想。
SOA
引入两个场景供大家思考。
- 一个用户进行下单操作，这个时候系统会首先检测数据库中的库存量是否足够，但是我们可能会存在着很多类似的业务场景，那么这个时候我们的系统就会多出很多冗余的业务代码，我们是否可以将这种检测逻辑单独拆分为一个可重用的服务呢？
- 一个很大的集团公司下有众多的子公司，但是每个子公司都有自己的一套业务模式和信息沉淀，但是不能互相通信和共享，这个时候虽然每个子公司都能创造一定的价值，但是无法使价值最大化，彼此之间形成了信息孤岛。
SOA，英文全称 Service-Oriented Architecture，意为面向服务的架构，我们也可以认为它和面向对象、面向过程、面向切面的思想是一样的，都是一种软件开发方式。
它的核心目的就是把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务，这些被提取出来的共享服务相对来说是独立的，并且可重用。
在SOA中，会采用ESB（企业服务总线）来作为系统和服务之间的通信方式。
SOA主要解决的问题就是：
- 信息孤岛
- 共享业务的重用
微服务
我们可以将微服务看作SOA的子集，也就是多个微服务可以组成一个SOA服务。
微服务关注的是解耦，降低业务间的耦合度。
而SOA则是关注的是服务间的重用及解决信息孤岛的问题。
每个微服务只关注某个特定的功能。
微服务架构的优点
- 复杂度可控：每个微服务只需要关注某个特定的业务领域，并通过定义良好的接口表述服务。维护简单，开发难度低，复杂度低，体积小。
- 技术选型灵活：每个微服务可以通过不同的团队来进行维护，每个团队都可以结合特定业务下最适合或者是团队更擅长的技术进行选型。
- 扩展性强：可以根据每个微服务的性能要求和业务特点来进行服务的灵活扩展。
- 独立部署：每个微服务都是一个独立运行的进程，所以可以实现独立部署。
- 容错性：在微服务架构中，其中的一个服务发生故障的时候，我们可以使故障隔离在单个服务中，其他服务可以通过重试、服务降级等机制来实现应用层面的容错。
