微服务架构的由来
在微服务架构出现之前，最常用的架构就是单体架构，俗称"一个jar(war)包打天下"。在一个jar包工程中，采用MVC架构，分为表现层，业务层，数据访问层，所有的业务模块，都放在这个工程中集成。 随着软件行业规模的增长，这种单体架构的弊端也越来越多，包括:
- 耦合性高，某个地方出问题，很可能影响其他业务模块的使用
- 代码管理成本高，项目沉重，并会随着需求的增加越来越重
- 随着访问量的增多，这种架构的工程并发力不够
为了解决单体结构带来的问题，就出现了微服务架构。 微服务架构就是将单一程序拆分成一个一个的微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。
微服务架构的核心技术
作为一种新型的软件架构模式，微服务架构需要借助一些核心技术来支撑实现。以下是微服务架构的核心技术：
服务注册与发现 服务注册与发现是微服务架构中的一个关键技术，它通过服务注册中心来管理各个服务实例，以便其他服务可以发现和调用这些服务。该技术避免了手工编写配置文件的繁琐过程，并且可以支持动态上线、下线以及负载均衡等功能。
负载均衡 负载均衡是指将请求合理地分配到不同的服务实例上，以实现高效的负载分布。常用的负载均衡算法有轮询法、随机法、加权轮询法以及最少连接法等。
高可用性 高可用性是指在系统出现故障时，能够自动切换到备用系统，保证系统的正常运行。常用的实现方式有双机热备、后备主机以及静态容错等。
服务网关 服务网关是微服务架构中的另一个关键技术，它可以作为前置设备，对外提供API和服务调用接口，同时也可以实现权限控制、流量控制和协议转换等功。
数据库技术 在微服务架构中，数据存储通常采用分布式数据库技术，如MySQL Cluster、NoSQL、Redis等，以提高数据的可用性和可扩展性。
微服务架构优势与劣势
优势：
复杂的业务拆分成多个业务，每个业务是一个独立的微服务，彻底的去耦合，利于分工，当需要增加业务的时候，可以方便创建新的微服务扩展业务，而不用担心有没有别的地方耦合
每个微服务都是独立部署的，如果其中一个宕机了，不会影响整个系统；也方便功能变更时，服务的部署；当流量增大后，可以将服务集群化部署，增强抗击高并发的能力
每个微服务之间可以使用不同的编程语言和不同的数据库。
劣势:
在复杂程度上来说，微服务比单体建构要更为复杂些
部署比单体项目复杂
服务之间是用HTTP协议通信的，通信成本比单体项目高
数据一致性问题。
适用场景
通过上面的描述可以看出，微服务在解决了单体架构带来的问题的同时，也出现了部署复杂，需要增加中间件联络各服务的问题。所以，不是所有的场景都推荐使用微服务架构，具体如下: 适用场景: ①:大型复杂的项目…(来自单体架构200W行代码的恐惧) ②:快速迭代的项目…(来自一天一版的恐惧) ③:并发高的项目…(考虑弹性伸缩扩容的恐惧)
不适场景: ①：业务稳定，就是修修bug ，改改数据 ②：迭代周期长 发版频率 一二个月一次
