1.微服务跟SOA有什么区别
可以把微服务当做去除了ESB的SOA。ESB是SOA架构中的中心总线，设计图形应该是星形的，而微服务是去中心化的分布式软件架构。
2.优点
每个服务足够内聚，足够小，代码容易理解、开发效率提高；服务之间可以独立部署，微服务架构让持续部署成为可能；每个服务可以各自进行负载均衡扩展和数据库扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；容易扩大开发团队，可以针对每个服务（service）组件开发团队；提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；系统不会被长期限制在某个技术栈上。
3.缺点
开发人员要处理分布式系统的复杂性；开发人员要设计服务之间的通信机制，对于需要多个后端服务的user case，要在没有分布式事务的情况下实现代码非常困难；涉及多个服务直接的自动化测试也具备相当的挑战性；服务管理的复杂性，在生产环境中要管理多个不同的服务的实例，这意味着开发团队需要全局统筹（PS：现在docker的出现适合解决这个问题）；应用微服务架构的时机如何把握？对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司，不需要考虑微服务架构模式，这时候最重要的是快速开发、快速部署、快速试错。
4.微服务架构的关键问题
（1）微服务架构的通信机制
客户端与服务器之间的通信
在单块应用架构下，客户端应用程序（web或者app）通过向服务端发送HTTP请求；但是，在微服务架构下，原来的单块服务器被一组微服务替代，这种情况下客户端如何发起请求呢？
客户端可以向micro service发起RESTful HTTP请求，但是会有这种情况发生：客户端为了完成一个业务逻辑，需要发起多个HTTP请求，从而造成系统的吞吐率下降，再加上无线网络的延迟高，会严重影响客户端的用户体验。
为了解决这个问题，一般会在服务器集群前面再加一个角色：API gateway，由它负责与客户度对接，并将客户端的请求转化成对内部服务的一系列调用。这样做还有个好处是，服务升级不会影响到客户端，只需要修改API gateway即可。加了API gateway之后的系统架构图如图5所示。
内部服务之间的通信
内部服务之间的通信方式有两种：基于HTTP协议的同步机制（REST、RPC）；基于消息队列的异步消息处理机制（AMQP-based message broker）。
Dubbo是阿里巴巴开源的分布式服务框架，属于同步调用，当一个系统的服务太多时，需要一个注册中心来处理服务发现问题，例如使用ZooKeeper这类配置服务器进行服务的地址管理：服务的发布者要向ZooKeeper发送请求，将自己的服务地址和函数名称等信息记录在案；服务的调用者要知道服务的相关信息，具体的机器地址在ZooKeeper查询得到。这种同步的调用机制足够直观简单，只是没有“订阅——推送”机制。
AMQP-based的代表系统是Kafka、RabbitMQ等。这类分布式消息处理系统将订阅者和消费者解耦合，消息的生产者不需要消费者一直在线；消息的生产者只需要把消息发送给消息代理，因此也不需要服务发现机制。
两种通信机制都有各自的优点和缺点，实际中的系统经常包含两种通信机制。例如，在分布式数据管理中，就需要同时用到同步HTTP机制和异步消息处理机制。
（2）分布式数据管理
处理读请求
在线商店的客户账户有限额，当客户试图下单时，系统必须判断总的订单金额是否超过他的信用卡额度。信用卡额度由CustomerService管理、下订单的操作由OrderService负责，因此Order Service要通过RPC调用向Customer Service请求数据；这种方法能够保证每次Order Service都获取到准确的额度，单缺点是多一次RPC调用、而且Customer Service必须保持在线。
还有一种处理方式是，在OrderService这边存放一份信用卡额度的副本，这样就不需要实时发起RPC请求，但是还需要一种机制保证——当Customer Service拥有的信用卡额度发生变化时，要及时更新存放在Order Service这边的副本。
处理更新请求
当一份数据位于多个服务上时，必须保证数据的一致性。
分布式事务（Distributed transactions） 使用分布式事务非常直观，即要更新Customer Service上的信用卡额度，就必须同时更新其他服务上的副本，这些操作要么全做要么全不做。使用分布式事务能够保证数据的强一致，但是会降低系统的可用性——所有相关的服务必须始终在线；而且，很多现代的技术栈并不支持事务，例如REST、NoSQL数据库等。
基于事件的异步更新（Event-driven asynchronous updates） Customer Service中的信用卡额度改变时，它对外发布一个事件到“message broker（消息代理人）”；其他订阅了这个事件的服务受到提示后就更新数据。
5.微服务架构的九大特性
服务组件化：
在微服务架构中，需要我们对服务进行组件化分解，服务是一种进程外的组件，它通过HTTP等通信协议进行协作，而不是像传统组件那样镶入式的方式协同工作，每一个服务都独立开发、部署、可以有效避免一个服务的修改引起整个系统的重新部署。
按业务组织团队：
在实施微服务架构时，需要采用不同的团队分割方法。由于每一个服务都是针对特定的业务的宽栈或者全栈实现的，纪要负责数据的持久化存储，又要负责用户接口定义等各种跨专业领域的职能。因此面对大型项目的时候，对于微服务团队的拆分更加建议按业务线的方法进行拆分，一方面可以有效的减少服务内部修改所产生的内耗，另一方面，团队边界可以变得更为清晰。
做产品的态度：
在微服务架构团队中，每个小团队都应该以做产品的方式，，对其整个生命周期负责，而不是像传统项目开发那样，交付给测试，运维为目标
智能端点和哑管道：
由于各个服务不在一个进程中，组件间的通信模式发生了改变，原本进程内的方法调用变成了RPC方式的调用，会导致微服务之间产生烦琐的通信，使得系统表现更为糟糕，所以我们需要更粗粒度的通信协议：
在微服务架构中，通常会使用一下两种服务调用方法：
（1）使用HTTP的RESTful API或者轻量级的消息发送协议，实现消息传递与服务调用的处触发。
(2) 通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间体。
在极度强调性能的情况下，还有可能会使用二进制的消息发送协议，例如protobuf
去中心化治理：
在整个微服务架构，通过采用轻量级的契约定义接口，使得我们队服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对不同的业务特点选择不同的技术平台。
去中心化管理数据：
在实施微服务架构时，希望每一个服务自己来管理其数据库，这就是数据管理的去中心化，虽然数据管理的去中心化让数据管理更加细致化，让数据存储和性能达到最优，但是不同的数据库实例，数据一致性也成了微服务架构中亟待解决的问题之一，分布式事务本身实现的难度就非常大，所以在微服务架构中，我们更强调各服务之间进行”无事务“的调用，而对数据一致性，只要求数据在最后的处理状态是一致的即可。
基础设施自动化：
在微服务架构中，务必从一开始就构建起”持续交付“平台来支撑整个实施过程；
容错设计：
在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计考虑的，通常我们都希望在每个服务中实现监控和日志记录的组件。比如：服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。
演进式设计
在初期， 以单体系统的方式来设计和实施， 一方面系统体量初期并不会很大， 构建和维护成本都不高。 另一方面， 初期的核心业务在后期通常也不会发生巨大的改变。
随着系统的发展或者业务的需要， 架构师会将一些经常变动或是有一定时间效应的内容进行微服务处理， 并逐渐将原来在单体系统中多变的模块逐步拆分出来， 而稳定不太变化的模块就形成一个核心微服务存在于整个架构之中。
6.微服务的设计原则如下：
●单一职责原则
指的是每一个微服务模块，只关心自己的业务规则。例如订单模块只关心订单的相关业务，不牵扯其他业务的逻辑。
●服务自治原则
每一个微服务模块的开发，需要有自己的开发、测试、运维、部署这一条独立的栈，并且有自己的数据库等一切，完全把其当成一个单独的项目来做，不牵扯到其它无关业务。
●轻量级通信原则
微服务的通信协议需要跨平台、跨语言的通信协议，因为微服务是不绑定技术栈的，不论使用Java、PHP还是.net去开发Web系统，它们之间的通信一定是去语言特色的。
●接口明确原则
前面提到了微服务的“接口调整成本高”，那么怎么去避免它呢？我们一开始就应该规划好微服务的模块是一种什么样的模型，尽量去避免A接口的改动会导致B接口的改动这种情况。