标签：小型 一致性 补偿机制 href 应用 爆发 完成 简介 情况
@
今天简单了解一下微服务，在看微服务前，先了解一下传统的单机系统。
所有的业务子模块都集中在一个系统中，优点是便于管理，但是规模变大的时候，缺点就很明显了。
缺点：
当产品规模越来越大，各种的大大小小模块都塞在一个项目中，必然会使整个项目变的臃肿，让开发者难以维护。
系统的各个功能模块都依赖于同样的数据库、内存等资源、一旦某个功能模块对资源处理不当，即可能影响整个系统。
当系统的访问量越来越大的时候，单体系统可以进行水平扩展，部署多台机器。
但是这种扩展并不灵活，假如我们的性能瓶颈在支付上，只希望对支付模块进行水平扩展，单体系统是无法做到的。
微服务，是近年来流行起来的一种架构思想，将单个的应用拆分成一套小型服务，每种应用都是一个独立的进程，通过轻量级机制(通常为http资源api)进行通信。
这些服务围绕业务功能构建，由于进程的独立性，这些小型服务可以使用不同的编程语言、数据存储技术。
微服务的优点
单体架构是以整个系统作为单位部署，而微服务则可以作为一个独立的组件单独部署。
举个例子，我们都知道每年双11的爆发访问量，而且基本会集中在凌晨。
那么假如系统瓶颈在于支付模块，需要300台机器，其次是订单只需要200台，用户只需要100台机器，那么我们采用微服务的话就可以进行如下部署。同时docker的流行，也为微服务器提供了有效的容器。
微服务的一个重要设计原则就是每一个微服务拥有独立的数据源，假如订单服务想读取用户服务的数据库，那么只能通过操作用户服务的接口完成。
同时，docker容器也做好了资源的有效隔离。
相比于传统架构，微服务架构更强调的是系统按业务边界做细粒度的拆分和部署。
那么微服务架构有哪些缺点呢：
微服务需要把原有的系统拆分成多个独立工程，同时需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，大大增加了设计和开发的难度。
微服务拆分过细可能会出现添加一个小功能需要改动好几个工程的情况，随着服务数量的增加，管理的复杂性也会随之增加。
所以说架构设计没有什么绝对的，主要还是看场景，如果不在大厂的话，一般很难遇到复杂的微服务架构吧。
标签：小型 一致性 补偿机制 href 应用 爆发 完成 简介 情况
原文地址：https://www.cnblogs.com/ailumiyana/p/12045547.html
