微服务架构实战笔记微服务架构实战笔记
微服务架构的优势与不足
优势
1.更简单:通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下,应用被分解为多个可管理的分
支或服务。
2.自由选型:这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术,提供API服务
3.部署独立:微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响
4.服务独立扩展:你可以根据每个服务的规模来部署满足需求的规模。甚至于,你可以使用更适合于服务资源需求的硬件。
劣势
1.微服务强调了服务大小:拆太小?
2.微服务应用是分布式系统,由此会带来固有的复杂性:开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更
甚于,他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事,但相对于单体式应用
中通过语言层级的方法或者进程调用,微服务下这种技术显得更复杂一些。
3.分布式交易/事务问题
4.测试复杂:同样的服务测试需要启动和它有关的所有服务
5.微服务架构模式应用的改变将会波及多个服务:比如,假设你在完成一个案例,需要修改服务A、B、C,而A依赖B,B依赖
C
6.部署一个微服务应用也很复杂:一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需
要配置诸如数据库和消息中间件等基础服务。相对比,一个微服务应用一般由大批服务构成。
使用API Gateway
客户端到微服务直接通信
不幸的是,这个方案有很多困难和限制。其中一个问题是客户端的需求量与每个微服务暴露的细粒度API数量的不匹配。如图
中,客户端需要7次单独请求。在更复杂的场景中,可能会需要更多次请求。例如,亚马逊的产品最终页要请求数百个微服
务。虽然一个客户端可以通过LAN发起很多个请求,但是在公网上这样会很没有效率,这个问题在移动互联网上尤为突出。这
个方案同时会导致客户端代码非常复杂。
另一个存在的问题是客户端直接请求微服务的协议可能并不是web友好型。一个服务可能是用Thrift的RPC协议,而另一个服
务可能是用AMQP消息协议。它们都不是浏览或防火墙友好的,并且最好是内部使用。应用应该在防火墙外采用类似HTTP或