从单体结构到微服务架构的转变，微服务入门

单体架构 VS 微服务架构

1.1从单体架构说起

一个工程对应一个归档包(war)，这个war包 包含了该工程的所有功
能。我们成为这种应用为单体应用，也就是我们常说的单体架构(一个
war包打天下)。

具体描述: 就是在我们的一个war包中，聚集了各种功能以及资源，比如JSP、JS、CSS、HTML等。
而业务中包含了我们的用户模块，订单模块，支付模块等等.

单体架构图

1.3单体结构优缺点总结

优点：

• 架构简单明了，没有”花里胡哨“的问题需要解决。
• 开发，测试，部署简单 （尤其是运维人员 睡着都会笑醒）

缺点：

• 随着业务扩展，代码越来越复杂，代码质量参差不齐(开发人员的水平不一),会让你每次提交代码 ，修改每一个小bug都是心惊胆战的。
• 部署慢(由于单体架构，功能复杂) 能想像下一个来自 200W+ 代码部署的速度。
• 扩展成本高，根据单体架构图 假设用户模块是一个CPU密集型的模块(涉及到大量的运算)那么我们需要替换更加牛逼的CPU，而我们的订单模块是一个IO密集模块（涉及大量的读写磁盘）,那我们需要替换更加牛逼的内存以及高效的磁盘。但是我们的单体架构上 无法针对单个功能模块进行扩展，那么就需要替换更牛逼的CPU 更牛逼的内存 更牛逼的磁盘 价格蹭蹭的往上涨。
• 阻碍了新技术的发展…比如我们的web架构模块 从struts2迁移到springboot，那么就会成为灾难性

2、微服务及微服务架构

2.1 微服务的定义

微服务核心就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程，每个服务都能够单独部署，甚至可以拥有自己的数据库。这样的一个一个的小服务就是 微服务.

• 比如传统的单机电商应用, 一个商城系统里面有 订单/支付/库存/物流/积分等模块(理解为servcie)

• 我们根据 业务模型来拆分,可以拆分为 订单服务，支付服务，库存服务，物流服务，积分服务

若不拆分的时候，我的非核心业务积分模块 出现了重大bug 导致系统内存溢出，导致整个系统宕机.
若拆分之后，只是说我的积分微服务不可用，我的整个系统核心功能还是能使用。

有个大佬对微服务的定义与理解总结的比较好，这里我只是引用了一点浅明易懂的语言来初步了解微服务，想了解更多的可参考大佬博客：http://blog.cuicc.com/blog/2015/07/22/microservices/

2.2单机架构的扩展与微服务的扩展

//待续，有时间接着写