什么是微服务
在了解微服务之前，必须知道与微服务对应的单体式(Monolithic )表达式体系结构。 在Monolithic体系结构中，系统通常采用分层体系结构模式，并按技术维度对系统进行分类，包括可持续发展层、业务逻辑层和表示层。 Monolithic体系结构主要存在以下问题： 系统之间通常作为API相互访问，绑定紧密，难以维护。
各业务领域需要采用相同的技术堆栈，难以快速应用新技术；
所有对系统的更改都必须在整个系统中重新部署/升级，运输成本很高
在系统负荷增加的情况下，水平扩展变得困难；
如果系统中的某个地方出现问题，就会影响整个系统。
为了解决这些问题，微服务体系结构应运而生。 微服务也称为微服务体系结构。 微服务体系结构是一种体系结构类型，它将复杂的APP应用程序划分为多个独立自主的服务，并在服务和服务之间以松散耦合的形式进行交互。
例如，在以下示例中，将一个系统的后端划分为三个微服务：帐户/库存/shipping，每个微服务具有自己的数据库存储，对外提供样式一致的REST API
微服务的主要特征
单一职责
每项微服务都需要满足单一职责原则，微服务本身凝聚，因此微服务通常很小。 例如，每个微服务按业务逻辑分类，每个微服务只负责自己属于自己业务领域的功能。
微服务的开发通常与DevOps相结合，例如根据亚马逊提供的经验，一个微服务应该可以由一个Two Pizza Team负责设计、开发、测试和运输。
自治制度
微服务是独立的实体，可以独立部署和升级，服务和服务之间通过REST等形式的标准接口进行通信，微服务的实例可以被其他实现代替，而不影响其他微服务
例如，可以用具有相同接口的不同实现方法的实例替换示例帐户服务。 替换后，不影响其他服务。 或者，如果修复了错误，则灰度升级技术允许其他服务在升级期间使用帐户服务提供的服务。
为什么需要微服务
逻辑清楚
这一特点是微服务单一责任的要求带来的。 负责明确业务的微服务肯定比复杂系统更容易逻辑理解。
逻辑清晰是微服务的可维护性，当我们对微服务进行修改时，可以更容易地分析这种修改会产生什么影响，通过完整的测试来保证修改质量。
简化部署
在一个系统中，只需修改一行代码，就需要重建、测试整个系统并部署整个系统。 微服务可以引入微服务。
这样做的一个好处是，您可以更频繁地修改软件，以更低的成本快速发布新功能。
可扩展
适应系统业务增长的方法通常在向外扩展或向上扩展的方向上扩展。 在分布式系统中，通常用Scale out方式进行扩展。 由于每个功能都会面临不同的负载变化，因此采用微服务的系统比单个系统具有更好的可扩展性。
灵活的组合
在微服务架构中，将现有的微服务组合起来可以实现功能复用的目的。
例如，如果添加Booking Service，则可以在保留时直接重用Account Service和Inventory Service以检查用户权限和库存情况。
异构技术
在大型系统中，不同的功能可能有不同的特征，不同的团队可能有不同的技术能力。 由于微服务之间的松散耦合，不同的微服务可以选择不同的技术堆栈来开发。
另外，应用新技术时，可以只快速改造一个微服务，不影响系统内的其他微服务，有利于系统的发展。
例如，由于清单系统中的数据量较大，如果需要将数据从当前sqlite数据库更改为MySQL，则无需替换整个系统中的所有数据库，只能更改库存服务。
高可靠性
微服务之间独立配置，一个微服务的异常其他微服务不会同时异常。 可以避免隔离、熔断等技术大大提高微服务的可靠性。
微服务的缺点
复杂度高
由于微服务之间以REST、RPC等形式进行交换，因此对于Monolithic模式下的API形式，需要考虑调用方的故障、过载、消息丢失等各种异常情况，代码逻辑变得更加复杂。
对于微服务之间的事务操作，由于每个微服务都使用不同的数据库，因此无法利用数据库本身的事务机制来保证一致性，需要引入两阶段提交等技术。
另外，如果微服务之间存在共同功能的一部分，但不能提取为微服务，则每个微服务通常需要对该功能的一部分进行重复开发，或者至少进行代码复制，以避免微服务之间的耦合，从而实现开发副本
运输维度复杂
采用微服务体系结构时，系统由多个独立运行的微服务组成，需要设计良好的监控系统监测各微服务的运行状态。 运输业者必须对系统有详细的了解，才能建立更好的运输系统。
影响性能
相对于Monolithic架构，微服务之间以REST、RPC等形式进行
行交互，通信的时延会受到较大的影响。总结
微服务在近几年大火，它具备了灵活部署、可扩展、技术异构等优点，但同时也带来了开发、运维的复杂性。是否要采用微服务架构需要根据系统的特点，结合企业的组织架构、团队能力等多个方面进行综合的判断，而不是为了微服务而微服务。
个人建议，在开发一个新的系统时，因为业务逻辑和系统边界还不是那么清晰，可以先采用Monolithic方式开发，直到能够识别出稳定逻辑后再进行微服务的拆分，从而避免因为边界不清而进行重划分所带来的返工。