微服务

微服务的特性:
1. 每个微服务可独立运行在自己的进程里;
2. 一系列独立运行的微服务共同构建起整个系统;
3. 每个服务为独立的业务开发,一个微服务只关注某个特定的功能,例如订单管理,用户管理等..
4. 微服务之间通过一些轻量的通信机制进行通信,例如通过Rest API进行调用;
5. 可以使用不同的语言与数据存储技术;
6. 全自动的部署机制;

微服务的设计原则:
单一职责原则:
服务自治原则:是指每个微服务应该具备独立的业务能力,依赖与运行环境。
轻量级通信原则:
接口明确原则:每个服务的对外接口应该明确定义,并尽量保持不变。

微服务架构的优点:
1. 易于开发和维护
一个微服务只关注一个特定的业务功能,所以它的业务清晰,代码量较少。开发和维护单个微服务相对是比较简单的。而整个应用是由若干个微服务构建而成的,所以整个应用也会维持在可控的状态。
2. 单个微服务启动较快
单个微服务代码量较少,所以启动会比较快。
3. 局部修改容易部署
单体应用只要有修改,就要从新部署整个应用,微服务解决了这样的问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。
4. 技术栈不受限
在微服务中,我们可以结合项目业务及团队的特点,合理的选择技术栈,例如某些服务可使用关系型数据库MySQL;某些服务有图形计算的需求,我们可以使用Neo4J;甚至根据需要,部分微服务使用java开发,部分微服务使用NodeJS进行开发。
5. 按需伸缩
我们可以根据需求,实现细粒度的扩展。例如:系统中的某个微服务遇到了瓶颈,我们可以结合这个微服务的业务特点,增加内存,升级CPU或者增加节点

微服务的缺点:
1. 运维要求比较高,跟多的服务意味着更多的运维投入,在单体架构中,只需要保证一个应用的正常运行;而在微服务中,需要保证及时甚至几百个服务的正常运行与协作,这给项目的运维带来了很大的挑战。
2. 分布式固有的复杂性
使用微服务构建的是分布式系统,对于一个分布式系统,系统容错,网络延迟,分布式事务等都给我们带来了很大的挑战。
3. 接口调整成本高
微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有使用了该接口的微服务都需要做调整。
4. 重复劳动
很多服务可能都会使用到相同的功能,而这个功能并没有达到分解为一个微服务的程度,这个时候,可能各个微服务都会开发这个功能,从而导致代码重复。

据我使用过的微服务有Dubbo,当然还有其他我知道的但是没有用过的,比如接下来我要研究的SpringCloud。