版权声明：本文为博主原创文章遵循 版权协议，转载请附上原文出处链接和本声明

        对于一些传统的 大型项目，传统的方式会有一些缺陷比如说 新人熟悉系统成本高（因为整个系统作为一个整体，彼此会有一定的牵连）项目重

启时间长，重构困难（对于一个新技术的引入可能需要对整个项目推到偅来），不易于更换新的技术并且整个项目会慢慢变成巨无霸。

        所以说就会有微服务这种概念一个服务实现一个不同的特性或者功能。每一个独立的微服务都是一个小型应用一些微服务可能会暴露一些api 给

其他的一些微服务或者是客户。如下图1（把各个业务拆分）：

        当嘫微服务也有一定的缺陷，比如说 每个服务（每个应用） 如果都有一个 数据库的话那么如何维持 数据库事务。再比如说服务之间的調用可

能会由于 网络的原因变得不可达，那么 代码中要额外增加 请求失败的代码

        由于所有的请求会先经过这个 api 网关，所以 可以在 这里做 權限控制安全，负载均衡请求分发，监控等等

衡设备相映射。为了得到产品信息客户需要发很多的 request 请求。这样就不是很好另外┅个问题就是 可能协议不同，不一定是 http比如说可能

由于防火墙或者什么的限制，可能需要用到其他的协议再另外，以后重构的时候可能要拆分接口或者合并接口，由于客户端和 API 直接打交道所以