SOA & EDA & Rest & MicroService & ESB

1. https://en.wikipedia.org/wiki/Service-oriented_architecture
2. https://en.wikipedia.org/wiki/Event-driven_architecture
3. http://www.searchsoa.com.cn/showcontent_43152.htm
4. 微服务与SOA之间差了一个ESB

   四、微服务架构的关键问题

   1. 微服务架构的通信机制

   (1)客户端与服务器之间的通信

   在巨石型架构下，客户端应用程序(web或者app)通过向服务端发送HTTP请求;但是，在微服务架构下，原来的巨石型服务器被一组微服务替代，这种情况下客户端如何发起请求呢?

   如图4中所示，客户端可以向micro service发起RESTful HTTP请求，但是会有这种情况发生：客户端为了完成一个业务逻辑，需要发起多个HTTP请求，从而造成系统的吞吐率下降，再加上无线网络的延迟高，会严重影响客户端的用户体验。

   

   为了解决这个问题，一般会在服务器集群前面再加一个角色：API gateway，由它负责与客户度对接，并将客户端的请求转化成对内部服务的一系列调用。这样做还有个好处是，服务升级不会影响到客户端，只需要修改 API gateway即可。加了API gateway之后的系统架构图如图5所示。

   (2)内部服务之间的通信

   内部服务之间的通信方式有两种：基于HTTP协议的同步机制(REST、RPC);基于消息队列的异步消息处理机制(AMQP-based message broker)。

   Dubbo是阿里巴巴开源的分布式服务框架，属于同步调用，当一个系统的服务太多时，需要一个注册中心来处理服务发现问题，例如使用ZooKeeper这类配置服务器进行服务的地址管理：服务的发布者要向ZooKeeper发送请求，将自己的服务地址和函数名称等信息记录在案;服务的调用者要知道服务的相关信息，具体的机器地址在ZooKeeper查询得到。这种同步的调用机制足够直观简单，只是没有“订阅——推送”机制。

   AMQP-based的代表系统是Kafka、RabbitMQ等。这类分布式消息处理系统将订阅者和消费者解耦合，消息的生产者不需要消费者一直在线;消息的生产者只需要把消息发送给消息代理，因此也不需要服务发现机制。

   两种通信机制都有各自的优点和缺点，实际中的系统经常包含两种通信机制。例如，在分布式数据管理中，就需要同时用到同步HTTP机制和异步消息处理机制。

   2. 分布式数据管理

   (1)处理读请求

   在线商店的客户账户有限额，当客户试图下单时，系统必须判断总的订单金额是否超过他的信用卡额度。信用卡额度由CustomerService管理、下订单的操作由OrderService负责，因此Order Service要通过RPC调用向Customer Service请求数据;这种方法能够保证每次Order Service都获取到准确的额度，单缺点是多一次RPC调用、而且Customer Service必须保持在线。

   还有一种处理方式是，在OrderService这边存放一份信用卡额度的副本，这样就不需要实时发起RPC请求，但是还需要一种机制保证——当Customer Service拥有的信用卡额度发生变化时，要及时更新存放在Order Service这边的副本。

   (2)处理更新请求

   当一份数据位于多个服务上时，必须保证数据的一致性。

   分布式事务(Distributed transactions)使用分布式事务非常直观，即要更新Customer Service上的信用卡额度，就必须同时更新其他服务上的副本，这些操作要么全做要么全不做。使用分布式事务能够保证数据的强一致，但是会降低系统的可用性——所有相关的服务必须始终在线;而且，很多现代的技术栈并不支持事务，例如REST、NoSQL数据库等。

   基于事件的异步更新(Event-driven asynchronous updates) Customer Service中的信用卡额度改变时，它对外发布一个事件到“message broker(消息代理人)”;其他订阅了这个事件的服务受到提示后就更新数据。事件流如图6所示。

   

   
   

5. SOA和微服务架构的区别？