传统架构（单体架构）和微服务的区别

传统架构的问题

（1）单块应用，耦合严重
（2）开发速度慢，新需求
（3）不易于扩展和重构
（4）不易于技术升级

一个java web工程，多个工程，maven整合起来，spring mvc -> spring -> mybatis

一个工程，可能就包含几十万行代码

各种业务模块，全部耦合在一个大的工程中，公用了很多的基础代码

开发速度慢，开发流程，代码管理工具，签出最新的代码副本到本地，运行一下，保证可以运行

做自己的开发，你的代码跟其他人的代码都耦合在了一起，然后可能还需要涉及到跟其他的代码要做持续集成，然后放在一起统一测试，统一回归，然后统一部署和发布

每次部署都非常重，因为你要考虑到别人的代码，依赖的一些基础环境是否ok，打包和部署，都特别慢

很可能不小心别人的代码bug，导致你的系统部署失败，回滚，你还要通知别人，跟别人一起去调试和找到它的bug在哪儿

多人写作开发一个工程，经常涉及到各种代码的冲突，解决冲突，搞出来一些bug，重新运行多大几千个，上万个单元测试，重新经历后续的所有测试环境

软件迭代开发的速度很慢，可能迭代一个小功能，就要一周时间，一个模块，半个月的时间

微服务架构的几大特征

（1）足够单一的职责与功能
（2）非常的微型
（3）面向服务的思想
（4）独立开发：团队，技术选型，前后端分离，存储分离，独立部署
（5）自动化开发流程：编码，自动化测试，持续集成，自动化部署

用最简单的话来说，比如之前，可能就一个单块应用，几十个兄弟在一个代码上开发，商品模块，价格模块，库存模块，促销模块，o2o模块，全部放一起了

微服务，把几十万行的单块应用，拆分出多个服务，每个服务对应一个工程，每个工程就几百行到几千行代码

每个服务，职责很单一，负责一块事情，商品数据的管理，商品服务; 价格服务，管理复杂的价格变更的业务; 库存服务，管理复杂的库存变更的业务

微型：几百行~几千行代码

面向服务的思想：每个服务暴露出来一堆接口，然后其他人都是依赖你的服务在开发

独立开发：工程上完全独立了， 那就可以给不同的服务配置不同的团队，或者工程师去开发。商品服务是3个哥儿们在维护，价格服务是1个应届生在做，库存服务是2个哥儿们在做

不同的人就做不同的工程，维护自己不同的代码，spring mvc + spring + mybatis，php，go，c++

技术选型：mysql，mongodb，memcached，redis，hbase

每个服务都是自己的存储，单独对接自己的前端工程师，独立的部署在自己的机器上
独立开发，跟其他人没关系

微服务的作用

（1）迭代速度：你只要管好自己的服务就行了，跟别人没关系，随便你这么玩儿，修改代码，测试，部署，都是你自己的事情，不用考虑其他人，没有任何耦合
（2）复用性：拆分成一个一个服务之后，就不需要写任何重复的代码了，有一个功能别人做好了，暴露了接口出来，直接调用不就ok了么
（3）扩展性：独立，扩展，升级版本，重构，更换技术
（4）完全克服了传统单块应用的缺点

微服务的缺点

（1）服务太多，难以管理
（2）微服务 = 分布式系统，你本来是一个系统，现在拆分成多块，部署在不同的服务器上，一个请求要经过不同的服务器上不同的代码逻辑处理，才能完成，这不就是分布式系统
（3）分布式一致性，分布式事务，故障+容错

微服务的技术栈

（1）领域驱动设计：微服务建模

你的任何业务系统都有自己独特的复杂的业务，但是这个时候就是有一个问题，怎么拆分服务？拆成哪些服务？拆成多大？每个服务负责哪些功能？

微服务的建模，模型怎么设计

领域驱动的设计思想，可以去分析系统，完成建模的设计

这里不讲解了，一定是要拿超级复杂的业务来讲解，你才能听懂，业务采取的还是比较简单的，领域驱动

至少如果你真的很了解你的业务的话，你大概也知道应该如何去拆分这个服务

（2）Spring Cloud：基础技术架构

各个服务之间怎么知道对方在哪里，比如服务的注册和发现

服务之间的调用怎么处理，rpc，负载均衡

服务故障的容错

服务调用链条的追踪怎么做

多个服务依赖的统一的配置如何管理

（3）DevOps：自动化+持续集成+持续交付+自动化流水线，将迭代速度提升到极致

如果要将微服务的开发效率提升到最高，DevOps，全流程标准化，自动化，大幅度提升你的开发效率

（4）Docker：容器管理大量服务

微服务，一个大型的系统，可以涉及到几十个，甚至是上百个服务，比较坑，怎么部署，机器怎么管理，怎么运维

图文说明