微服务架构下的分布式
- 微服务架构的演变
- 单体架构
- SOA 架构
- 微服务架构和分布式
- 微服务的优点、缺点
- 优点
- 缺点
微服务架构的演变
微服务是一种服务间松耦合的、每个服务之间高度自治并且使用轻量级协议进行通信的可持续集成部署的分布式架构体系。一般业务系统发展历程都是基本相似的，从单体应用到多应用，从本地调用到远程调用。
单体架构
单体架构是最简单的软件架构，常用于传统的应用软件开发以及传统 Web 应用。传统 Web 应用，一般是将所有功能模块都打包（jar、war）在一个 Web 容器（JBoss、Tomcate）中部署、运行。随着业务复杂度增加、技术团队规模扩大，在一个单体应用中维护代码，会降低开发效率，即使是处理一个小需求，也需要将所有机器上的应用全部部署一遍，增加了运维的复杂度。选择单体应用架构模式的，一般都是网络流量比较小，由于只需一个应用，所有业务的功能都打包为了一个 War 包进行部署，这样可以减少机器资源和部署的繁琐，但是单体应用由于不同的业务相互纠缠在一起，开发起来比较费劲，并且由于所有功能都在一个应用里面运行，如果一个业务出现导致 JVM 死掉的异常，那么整个应用的功能就都瘫痪了。
SOA 架构
随着业务的发展，网站的流量会越来越大，简单的通过加机器的方式可以带来的承受流量冲击的能力也越来越低，这时候就会考虑根据业务将单体应用拆成若干个功能独立的应用，单体应用拆为多个应用后，由于不同的应用开发对应的功能，所以多应用开发之间可以独立开发而不用去理解对方的业务，另外不同的应用模块只承受对应业务流量的压力，不会对其他应用模块造成影响。
单体服务的拆分，拆分的方式一般有水平拆分和垂直拆分。垂直拆分是把一个应用拆成松耦合的多个独立的应用，让应用可以独立部署，有独立的团队进行维护；水平拆分是把一些通用的，会被很多上层服务调用的模块独立拆分出去，形成一个共享的基础服务，这样拆分可以对一些性能瓶颈的应用进行单独的优化和运维管理，也在一定程度上防止了垂直拆分的重复造轮子。
SOA 也叫面向服务的架构，从单体服务到 SOA 的演进，需要结合水平拆分及垂直拆分。SOA 强调用统一的协议进行服务间的通信，服务间运行在彼此独立的硬件平台但是需通过统一的协议接口相互协作，也即将应用系统服务化。
微服务架构和分布式
经过拆分，单体应用变为了包含多个应用的分布式系统了，在单体应用时，不同业务模块相互调用直接在本地 JVM 进程内就可以完成，而变为多个应用时候，相互之间进行通信的方式就不能简单的进行本地调用了，因为不同业务模块部署到了不同的 JVM 进程里面，更常见的是部署到了不同的机器，这时候一个高效、稳定的 RPC 远程调用框架就变得非常重要，Dubbo 就是阿里巴巴开发的一个开源的高性能的远程服务调用框架。
微服务可以很好得和容器技术结合，容器技术比微服务出现得晚，但是容器技术的出现让微服务的实施更加简便，目前 Docker 已经成为很多微服务实践的基础容器。因为容器的特色，所以一台机器上可以部署几十个、几百个不同的微服务。如果某个微服务流量压力比其他微服务大，可以在不增加机器的情况下，在一台机器上多分配一些该微服务的容器实例。
微服务的优点、缺点
优点
独立部署
测试容易
可伸缩性强
可靠性强
跨语言程度会更加灵活
团队协作容易
系统迭代容易缺点
运维成本过高，部署数量较多
接口兼容多版本
分布式系统的复杂性
分布式事务
问题定位：单体应用的日志集中在一起，出现问题定位很方便，而分布式环境的问题定界定位，日志分析都较为困难。
