何谓微服务?
简单来说,微服务架构就是将一个完整的应用从数据存储开始垂直拆分成多个不同的服务,每个服务都能独立部署,独立维护,独立扩展,服务与服务间通过RESTful API的方式互相调用。
我们为什么要采用微服务?
“让我们的系统尽可能快地响应变化”—— Rebecca Parson
微服务的优势:
每个服务都很简单,只关注于一个业务功能。
每个微服务可以由不同的团队独立开发。
微服务是松散耦合的。
微服务可以通过不同的编程语言与工具进行开发。
微服务的缺点:
微服务应用的是分布式系统,由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。相对于单体式应用中通过语言层级的方法或者进程调用,微服务下这种技术显得更复杂一些。
微服务的另一个难题来自于分区的数据库架构。微服务架构应用中,需要更新不同服务所使用的不同的数据库。这对开发者提出了更高的要求和挑战。
部署难题。微服务架构模式应用的改变将会波及多个服务。比如,假设你在完成一个案例,需要修改服务A、B、C,而A依赖B,B依赖C。在单体式应用中,你只需要改变相关模块,整合变化,部署就好了。
依米观点:
做微服务之前,需要审视一下,目前的业务场景、技术实力,是不是需要把应用拆分到“微”的粒度。优雅的架构总是和实用的架构有距离的。在没有足够的能力之前,应该尽量选择更实用的架构。如果你的体量还不大,首先应该解决的是搭建好一套绝对稳定的平台化服务,待体量逐渐长大,再去根据实际需要进行不断发分裂。团队也随之变化。如果体量足够大,饱受单体应用之苦,也应该先建设平台化服务,建设好之后,先按照大的粒度进行拆分,逐步“微”化。