背景
随着业务需求的日渐复杂以及产品迭代节奏的不断加快,业务开发部门面临着前所未有的压力。为了抢占先机,用最快的速度准确把握用户需求的变化,优化开发出来的业务产品,微服务(MicroServices)架构技术在各大企业不断生根发芽。
微服务架构可以极大的降低业务的复杂性。开发和部署相对大单体架构而言更加简单,单个微服务的功能可以更快地更改,启动和调试单个微服务的时间成本相比于单体应用也大大减少。普遍而言,微服务架构具备以下优点:
- 将业务分而治之,降低业务复杂性,让业务易于理解、修改和维护
- 模块化部署,修改代价小,迭代速度快,有很好的扩展性
- 更好的容错性,业务服务各司其职,单点故障不易影响全局
然而微服务架构并非没有代价,就如软件工程中没有真正的银弹。
原来在单体架构时,所有的逻辑都在一个服务内处理,方法和方法之间是进程内部的调度方式,然而采用微服务架构之后,服务与服务之间需要通过网络相互沟通,一个业务的实现往往是多个服务的共同作用下完成,由此带来了一系列的问题。
企业微服务化面临的挑战
复杂的网络通信提升了故障出现的概率
在微服务架构体系中,服务与服务之间需要通过网络相互沟通,意味着研发人员在原本的业务逻辑之外,还需要额外考虑网络通信相关的问题。比如服务在向其上游服务发起请求时需要对上游服务的各种意外响应做出处理,常见的有401错