一：微服务&微服务架构 1：单体架构VS微服务架构 1.1)从单体架构说起 一个工程对应一个归档包（war），这个war包包含了该工程的功 能.
我们成为这种应用为单体应用，也就是我们常说的单体架构（一个 war包打天下).
具体描述：就是在我们的一个war包种，聚集了各种功能以及资源，比 如JSP JS CSS等.
而业务种包含了我们的用户模块，订单模块，支付模块等 等. 1.2)单体架构图 单体应用war 前端UI 用户模块 订单模块 支付模块 DB 1.3）单体架构优缺点总结 优点： ①：架构简单明了，没有”花里胡哨“的问题需要解决.
②：开发，测试，部署简单（尤其是运维人员睡着都会笑醒） 缺点： ①：随着业务扩展，代码越来越复杂，代码质量参差不齐（开发人员的 水平不一），会让你每次提交代码，修改每一个小bug都是心惊胆战 的.
②：部署慢（由于单体架构，功能复杂）能想像下一个来自200W代码部 署的速度 (15分钟） ③：扩展成本高，根据单体架构图假设用户模块是一个CPU密集型的模 块（涉及到大量的运算）那么我们需要替换更加牛逼的CPU，而我们的订 单模块是一个10密集模块（涉及大量的读写磁盘），那我们需要替换更 加牛逼的内存以及高效的磁盘.
但是我们的单体架构上无法针对单个 功能模块进行扩展，那么就需要替换更牛逼的CPU更牛逼的内存更牛 逼的磁盘价格蹭蹭的往上涨.
④：阻碍了新技术的发展.
.
.
.
.
.
比如我们的web架构模块从 struts2迁移到springboot，那么就会成为灾难性 1.4）微服务以及微服务架构 1.4.1）微服务的定义 ①：英文:martinfowler./articles/microservices.html ②:中文:blog.cuicc./blog/2015/07/22/microservices
1.4.2）微服务核心就是把传统的单机应用，根据业务将单机应用拆分 为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能， 个服务只做一件事，类似进程，每个服务都能够单独部署，甚至可以拥 有自己的数据库.
这样的一个一个的小服务就是微服务.
①:比如传统的单机电商应用，tulingshop里面有订单/支付/库存/物 流/积分等模块(理解为servcie) ②：我们根据业务模型来拆分，可以拆分为订单服务，支付服务，库存 服务，物流服务，积分服务 *③*若不拆分的时候，我的非核心业务积分模块出现了重大bug导致 系统内存溢出，导致整个服务岩机 ，若拆分之后，只是说我的积分微服务不可用，我的整个系统核心功能 还是能使用 在一个单一进程中 一个单体应用程序把它的功能放 个数服务架构把每个功能元素放进 个独立的服务中 这个单体进行扩展 并且通过在多个服务器上复制 票，只在需要时才复制 并且通过聘服务器分发这些服务进行扩 1.4.3）单机架构扩展与微服务扩展 ①：单机架构扩展
并发增加，从单机尔构族交为集容果构 Rginx 前法u1 前续u1 户 苗端川 用产 ②：微服务架构以及扩展 ③：微服务数据存储
单体-单一数据库 微服务-应用程序数据库 1.4.4)微服务架构是什么？
微服务架构是一个架构风格，提倡 ①：将一个单一应用程序开发为一组小型服务 ②：每个服务运行在自己的进程中 ③：服务之间通过轻量级的通信机制（httprestapi) ④：每个服务都能够独立的部署 ③：每个服务甚至可以拥有自己的数据库 1.4.5）微服务以及微服务架构的是二个完全不同的概念.
微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指 把一个一个的微服务组合管理起来，对外提供一套完整的服务.
1.4.6）微服务的优缺点 A：优点： ①：每个服务足够小，足够内聚，代码更加容易理解，专注一个业务功能 点（对比传统应用，可能改几行代码需要了解整个系统） ②：开发简单，一个服务只千一个事情.
（加入你做支付服务，你只要 了解支付相关代码就可以了） ③：微服务能够被2-5个人的小团队开发，提高效率 ④：按需伸缩 ：前后段分离，作为java开发人员，我们只要关系后端接口的安全性 以及性能，不要去关注页面的人机交互（H5工程师）根据前后端接口协 议，根据入参，返回json的回参
