微服务架构特点
微服务架构的特点与优势
1. 隔离性
在微服务架构中某个服务由于特殊原因变为不可用, 也不会影响其他服务的正常运行, 这种优势在单体应用程序是无法实现的, 单体变为不可用, 那么必定整个服务也变为不可用.
2. 可拓展性
庞大的单体程序如果出现了性能或者业务瓶颈, 那么只能在单体程序种继续维护迭代更新, 维护部署额代价很高, 但其实我们需要修改的仅仅是程序中的某个小功能或模块. 这个问题在微服务架构中得到了改善, 你只需要修改那些影响性能或者有问题的服务, 这样维护成本将会大大降低.
3. 简化部署
如果你的单体程序是一个庞大的单体服务, 那么即使你修改了一行代码, 那么也要重新部署整个应用程序, 而这简单的修改对于我们的服务来说是很耗时且影响是全局的. 这个问题在微服务中也得到了改善, 你只需要维护更新部署某一个或几个服务, 这样会使维护和部署成本大大降低, 即使线上除了问题那么也是某个或几个服务出现问题, 不会导致雪崩.
4. 容易优化
之所以说容易优化是因为在微服务架构中, 在业务架构层就该把整体的业务程序进行拆分, 拆分为不同的微服务, 这样单个服务中的代码量将会很少, 众所周知代码越少越好维护和优化.
微服务架构的劣势
微服务架构当然不是万能的, 其主要原因笔者认为是因为将单体服务拆分成多个分布式的服务导致的, 导致的问题主要是服务之间的通信, 以及通信的可靠性, 以及对这些服务的管理.
前辈们在微服务架构下提出了以下需要解决的问题.
1. 服务通信
原本的单体应用程序被拆分为了多个服务, 那么多个服务之间必定是要进行通信的, 网络中两端要通信一定要知道 ip:port/source. 那么如何在微服务架构中正确的得到目标服务的地址并且正确的调用到呢? 这就引入了服务注册与发现的概念.
常用的解决方案是引入注册中心, 每个服务启动的时候将自己服务本身的ip:port等信息上报给注册中心, 这个过程叫做服务注册, 服务调用方启动时会从注册中心获取所有可用服务信息(包括ip:port等)的列表, 并且订阅服务变更通知, 也就是其他服务信息变更且同步给注册中心的时候注册中心会将这些变更之后的服务信息同步给订阅服务变更的那些服务, 这个过程叫做服务发现.
2. 服务监控
运维的层面来讲我们需要实时掌握或者能看到每个服务的运行状态, 类似于Grafana那种UI能看到每个服务的资源占用调用次数以及负载等等, 这就需要我们有一套完善的监控体系来适配微服务架构.
3. 服务容错
生产环境上任何服务或程序都不可能永久安稳的运行下去, 都可能会出现过载, 宕机, 数据库宕掉等, 如果某个服务变为不可用后其依赖这个服务的其他服务会受到严重影响, 这个时候我们需要通过以下手段来解决服务之间容错.
熔断: 调用不可用的服务时将不进行调用, 直接返回失败信息.
降级: 调用不可用服务时返回一个默认的异常信息.
限流: 限制最大并发数.
超时: 请求持续时间超过x, 直接失败.