"为什么要搞“微服务架构”?这也是我们当初讨论的聚焦点。现在天天把“微服务”挂在嘴边的人很多,但是有多少人真正深入思考过“为什么”,我认为可能不多。
于是我在梳理材料的时候,就决定从源头入手——即“为什么”。
架构是演进的,不是一蹴而就。
"架构演进趋势图”中的趋势分析,在业界比较公认。这个图本身的内容,关于各个架构的描述,优缺点等等,网上简单搜索一下有大把大把的,感兴趣的同学可以自行搜索,毕竟这也不是我们文章的重点。
软件发展的不同时期,阶段,对技术的理解,选择和应用都有着不一样的诉求。架构的选型,永远只有“合适与不合适”,永远没有“哪个更好”的说法。我们今天来谈论微服务,并不是因为它更牛,而是经过谨慎分析,认为微服务的思想更符合我们的目标。
什么是“微服务架构”?
提到微服务,就没法不提到这位“大神”——马丁·福勒,他没有直接给微服务下一个精准的定义,而是给出了微服务特点的描述,大概从以下四个方面来说:
1。根据业务模块划分服务种类
2。每个服务可以独立部署并且互相隔离
3。通过轻量的API调用服务
4。服务需要保证良好的高可用性
在实际工作中,我们遇到过各式各样的问题,有些是技术问题,有些是业务问题,还有些是管理问题,这里拿其中一个案例来说一下。