隐藏秋招绝招：微服务架构五个问题

1：我们为什么需要使用微服务架构？或者说微服务能帮助我们解决什么问题？ 

思路：我们可以从微服务的对立面进行考虑，从单体应用存在的问题思考。

1. 随着业务的发展，开发变得越来越复杂。 修改、新增某个功能，需要对整个系统进行测试，重写部署。为了解决上述问题，微服务架构应运而生，简单来说，微服务就是将⼀个单体应⽤拆分成若干个小型服 务，协同完成系统功能的⼀种架构模式，在系统架构层面进行解耦合。
2.  各个模块使⽤同⼀种技术框架，局限性太大，很难根据业务选择最适合的技术架构。微服务架构拆分成小的模块之后的各个微服务之间进行通信 微服务之间只需要制定统⼀的协议即可，⾄于每个微服务使⽤什么技术框架来完成，统统不需要关心。 这种松耦合的⽅式使得开发、部署都变得更加灵活，同时系统更容易扩展，降低了开发、运维的难度。
3. 

2.微服务的优点

1. 各个服务之间实现了松耦合，彼此之间不需要关注对⽅是⽤什么语言开发，无论是python，java,c#等等，只需要保证自己的接⼝可以正常访问即可。通过标准协议访问其他接口即可。
2. 各个微服务之间独立管理，只需要专注于做好自己的业务，开发和维护不会影响到其他的微服务。 微服务是⼀种去中心化的架构方式，相当于每个人做好的零件，最终将其拼接在一起而不管过程是如何生产零件的。

3.微服务的缺点

1. 某个系统的远程调用出现问题时，导致微服务不可用，因为其是通过注册中心来调用的，因此就有可能产生级联反应，造成整个系统的崩溃。
2. 如果某个需求需要调用多个微服务，如何来保证数据的⼀致性。一般采用json。
3. 相比较于单体应用，微服务的学习难度会增加，对于新加⼊团队的员工来讲，如何快速掌握上手微服务架构，是⼀个问题。

4.微服务设计原则

1. 分析业务需求，从大到小提炼出核心需求，搞清楚服务间的交互关系，先拆分成粒度较大的服务，然后再根据具体的业务需求逐步细化服务粒度。
2.  各个微服务的功能职责尽量单⼀，避免出现多个服务处理同⼀个需求。避免出现高耦合。
3.  保证数据的独⽴性，各个微服务独立管理其业务模型下的数据。 使⽤ RESTful 协议完成微服务之间的协作任务，数据交互采用JSON 格式，方便调用和整合。
4. 

5.解决方案

1. Spring Cloud 微服务是⼀种分布式软件架构设计方式，具体的落地⽅案有很多，Dubbo、Spring Boot/Spring Cloud、Motan 等等，但是Spring Cloud 属于Spring全家桶里的一份子，基于 Spring Boot 使得整体的开发、配置、部署都非常方便，可以 快速搭建基于微服务的分布式应⽤，Spring Cloud 相当于微服务各个组件的集⼤成者。
2. SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。
3.