最近工作和心态发生了一点变化，对未来的自己提出了更高的要求，所以在阅读和思考上，更加严格的要求自己的了。

之前临时看了一本书《分布式服务架构：原理、设计与实战》，因为时间缘故，很多点都没有看到，现在相对时间充足了点，所以一边读，一边做总结。

记录、分析、总结、提高！

微服务和SOA的区别

SOA强调异构服务通过一个总线进行协作，有一个中心化的企业服务总线.微服务是没有这样一个总线的。

去中心化的理解

服务的核心数据：信息，没有在某个地方聚合进行传输。ESB不是去中心化，因为信息在企业服务总线进行了聚合。

流量都走网关的问题

前段时间和用户交流SpringCloud过程中，用户认为所有服务的流量都是通过了API网关进行了转发。

为了解释这个问题在交流过程中，提出了外部应用和内部应用2个概念。内部应用就是在Eureka Server 这类服务注册中心进行了注册的服务。外部应用反之。

内部应用因为在EurekaServer进行了注册，所以获取到内部服务节点的IP等关键信息，所以可以直接发起访问。

外部应用涉及到安全等原因，不能够获取到内部应用真实的IP地址，所以只给你暴露一个API网关的地址，流量由API进行转发。

言归正传 : 所有流量都走API网关的做法放大了API网关调用的TPS，API网关很容易遭遇到性能瓶颈。

三方库概念理解

• 一方库 : 通常是应用项目内部的依赖。比如A项目分为了：M1,M2,M3 若M1依赖M2, 那么M2就是M1的一方库。
• 二方库 : 内部合作方的库
• 三方库 : 开源的库，比如guava这些。

使用数据库作用交互中心的问题

假如有2个系统，其中A需要使用B提供的数据，一种做法是A和B共用一个数据库，B将数据采集后放入数据库中，A定时从A中查找数据。

这种设计在数据及时性要求不高的情况还是可以的，但是存在如下几个问题：

• 及时性，及时性肯定得不到保证。
• 数据库压力大，不管数据库有没有新数据，都要进行查询，压力过大。

服务雪崩

微服务之间调用走的是网络协议，不管是HTTP还是TCP都可能因为网络问题，存在不可靠的情况，迟迟无法回复信息。

比如A->B ，如果B所处的网络出现问题，此时又有很多A的请求发往B,A内部的线程池很快被占满。此时不仅仅A崩溃，依赖A的C也会崩溃，由此一个相互依赖的服务都有可能崩溃。

所以因为某些服务的异常，导致整个系统异常越来越大的过程，就是服务雪崩。

其他概念

• 系统的非功能性指标：高性能、高可用、可扩展、可伸缩、安全性。
• SOA有2个主流的实现：WebService和ESB
• 微服务提倡的是将软件分为多个：可独立开发、独立部署、可运行、可维护的子服务。

您有任何建议和意见，请Email联系： hicode_club@163.com

转载请保留出处 HiCode 俱乐部