前言
通过上一篇学习我们大体了解了单体架构的含义及优缺点，隐性的引申出微服务分布式体系的一些东西，接下来我们将开始真正走进微服务领域进行探索。从基本知识理念到技术，再到项目搭建。（字数很多，耐心阅读）
关于本章学习，我们可以从以下几点入手
1. 什么是微服务
2. 微服务的优缺点
3. 单体架构系统与微服务架构系统的对比
4. 微服务运用的场景(设计原则)
目录
一、什么是微服务
通过文字定义我们可以用最直白的语言去说，“微”等同于细致入微，“服务”等同于为用户提供功能支持。从系统架构层面简单来说：将服务大模块拆分成多个服务子模块，通过“服务总站”将多个子模块集中式地进行管理。
举例来说：电商分为用户模块，商品模块，订单模块等
从传统的单体架构体系来设计，这三个模块都同属于一个项目(war包)；从微服务的分布式体系来设计，这三大模块划分为独立的三个项目。
来看一看作为“微服务”这一名词的发明人Martin Fowler对微服务的定义：
二、微服务的优缺点
优点
从上述对Martin Flower 微服务理念的引进，我们可以对其进行拆分梳理：(优点)
1. 模块独立化 (从以前系统多模块的复杂性，到单元模块的服务)
2. 轻量级的机制通信 (数据交互大多是以HTTP协议进行通信)
3. 自动化部署，集中式管理
4. 支持多语言及不同数据存储
5. 分布式系统
关于开发
我们在日常代码维护中，讲究的是高效，健壮，可用，而微服务的引进极大地满足了我们这些日常需求。微服务是将复杂的业务拆分成多个单元服务，而我们针对业务需求进行开发的时候，不再对复杂业务进行大规模的设计和开发，而是将它拆分成多个子业务，只针对于子业务进行开发便可。这样每个开发人员只负责维护自己的区域而不用在管其它人的区域。
开发方式由宏观到微观，时间成本由多到少。无论是项目版本更新，提出多么复杂的功能需求，我们依然可以以微服务这样理念去划分，极大缩减了开发周期和成本，独立单元服务的稳定型边界，服务与服务之间没有任何的耦合。
关于维护
传统的软件开发模式背后团队领域都很齐全，UI负责作图，产品负责原型，前端负责网页设计，后端负责数据交互，测试确保项目不出任何问题，运维负责项目维护。虽然表面上看似坚不可摧，但往深了去看，本身所有的模块集中在一个项目中，模块的紧密性会牵扯到多个职位领域的参与，可能会遇到后端人员会参与到前端，运维；甚至是一个小业务会动用整个团队，这样显然是产生了弊端。
微服务的体系，就避免了这样弊端的存在，每一个职位领域负责本职工作而不会参与其它岗位人员的设计等。在维护方面极大的提高了工作效率，也大大提高了项目的稳定性，健壮性。
关于内部设计
1. 通信 - 数据传输
通常我们进行前后端数据交互的时候，都是以Json格式进行交互，少数以XML，Protobuf。Protobuf进行数据序列化生成二进制数据，反观Json虽然前者更轻量化，但可读性着实很差。Json与XML对比，无论是轻量传输还是可读，Json更适合。
也是为什么现在JSON会成为主流的数据交互方式那一定是有它的理由的。当然微服务单元之间一般倾向于HTTP通信机制，更多时候使用RESTFUL API。
跨语言使用也是微服务的优势之一，无论是Go，Java，PHP，Pythod等都可以进行服务之间的通信交互，也就是说Java可以编写业务提供给Pythod，同理也是一样。
2. 数据存储
微服务的分布式体系，业务模块的拆分可以使更多的单元服务使用不同的数据库。
庞大的项目，业务模块众多，如果针对于同一个数据库进行表操作，读写效率会随着数据的增多，表的设计而大幅度缩减。微服务体系我们可以针对于不同单元服务进行关系数据库和非关系数据库的选择，也可以进行关系数据库分库处理，相比于传统单体架构系统而言，显然微服务的分布式体系更加占有优势。
3. 结构优化
从CAP理念我们知道，单体架构基于CA设计，微服务大多是基于AP设计，具由高可用和分区容错的特点。高可用主要体现在7*24小时不间断的服务，随着用户量的增加，并发数也逐渐升高，对于高并发的处理，微服务的水平扩展能力尤为显著，可以进行微服务的集群化部署，从而增加系统的负载均衡。分区容错特点也使得微服务更加健壮。
4. 熔断器机制
微服务也具有熔断处理机制，不会引起服务之间的“雪崩效应”，还可以自动化执行自我修复机制。
所谓的“雪崩效应”，就是因为服务之间的强耦合性，使得一个服务运行出错，另一个服务有依赖于这个服务，用户不断去使用出错的服务，导致另一个服务压力堆积使之线程阻塞，有更多被依赖的服务牵连着而引起整个项目的崩溃。而熔断机制，在执行过程中会立即检查并停掉出错服务，本身是单元服务拆分，所以不会影响到其它服务的正常使用，避免了整个项目的崩溃，当然若有依赖此服务的单元服务也会被DOWN掉。
再者熔断器还有另一个机制是自我修复机制，也就是被DOWN掉的服务通过调试解决问题后依然在其它服务运行过程中正常使用，这就是“悄无声息”，不被其它人知道的情况下成功Up上了，这就是熔断器中自我修复机制，会经过一段时间会半打开熔断器来进行服务检测。(在这里给你一张图自行模拟熔断器机制)
关于部署
微服务具有集中式管理的特点，当然也拜托不了自动化部署，随着Docker技术的引进，我们不会在向以前那样将项目一列一列的打包，制定端口号等复杂操作，像Docker这样的技术已经实现了，只需集中编写，无需进行部署。(Jenkins还没开始学习，关于自动化部署这里推荐大家还是有必要看一看的)
微服务的缺点呢？
1. 分布式事务
我们知道数据读写讲究事务的基本原则，为了保证数据的一致性而不会引起脏读，幻读等，微服务的分布式体系对事务处理还是较为繁琐的。为什么？ 用一段伪代码来说明一下：
/*
* 传统项目中，因为没有服务拆分，所以只需要统一在一个模块区域里进行事务处理就可以
*/
@Transactional
public void updateTest() {
updateUser(); // 更新用户表
updateOrder(); // 更新订单表
}
微服务本身是服务拆分，所以得确保在服务与服务之间正常通信，非人为因素本身是不可避免的，所以很有可能造成一个服务的事务成功，另一个服务事务的回滚。
2. 微服务的繁琐
简单来说，服务之间的独立导致测试人员的成本开销；通信机制牵扯到数据层面的交互本身重中之重，所以得选择一个合适的机制来进行设计；服务与服务之间的建立，会造成有一个服务进行改动，而可能影响到另一个服务的改动。(这点可以人为协调解决)
3. 服务部署
每一个单元服务相当于一个项目，除了内存的开销以外，还有其项目本身所运用到不同的中间件等，这些复杂的业务程序在运维期间稍有不测，会影响到服务本身。
4. 服务拆分
微服务的微到底是拆分到什么样的层次，我们也不能具体的划分。可以拆成一个接口一个项目，也可以拆成多个接口一个项目，所以这样的边界值是不定因素。
三、单体架构系统与微服务架构系统的对比
1. 从开发角度来说：前者效率低于后者
因为后者模块进行了拆分，侧重角度明确，耦合性极低。
2. 从部署角度来说：前者效率低于后者
因为后者支持集中式管理，自动化部署。
3. 从性能角度来说：优化相同的情况下，前者低于后者
前者CA设计理念，后者AP设计理念，可用型强，具有分区容错特点。
4. 从错误处理角度来说：前者低于后者
后者支持熔断机制，大幅度避免了雪崩效应
5. 从业务复杂性的角度来说：
前者适合用户量少，业务模块不是很多的应用；后者适合用户量多，业务模块复杂的应用
四、微服务运用的场景
以我的想法来说，首先从用户量，领域，需求等有个大体的评估，确定了项目的走势，在决定是否使用微服务分布式架构体系，还是单体架构体系。
运用场景，比如：淘宝，京东，爱奇艺等这些基于百万级以上的用户量而言，更适合微服务的分布式体系；比如：公司官网，小应用等这样用户量，需求量不是很多而言，单体架构体系更为合适之选。
五、总结
以上是对微服务理念的大体介绍，通过对本篇的学习，我们也了解到了微服务之所以那么火热的原因，也了解了与传统大体架构体系项目的不同之处。
在今后，我们便可以针对于不同产品需求和走势选择不同的架构体系去做。不得不说，写一篇博客确实有些累，3个小时，一边学习一边总结也算收获满满了。下一篇我们将真正开始接触SpringCloud，虽然大多还是理论支持，但一分耕耘一分收获，稳扎稳打才是重要。