1. 微服务架构的优缺点

1. 演变而来（从单体应用演变过来）
2. 初期评估起手就上微服务

1.1. 面相服务单一职责

避免业务重复开发

1.2. 分工协作

单体：影响开发效率,发布和迭代性差；项目启动慢，每个人对整体的项目都要有所把握；业务缩减后如果
语言不一致开发人员面临流失。
拆分：提高开发效率和敏捷性；单个服务启动快，专人处理专事专注自己的服务；充分利用项目开发人员
（哪怕是不同的语言不同框架，不同存储技术，也可以）

1.3. 并发能力

单体：整体集群，易造成系统资源浪费；之前下单功能要去集群无法准确评测最大并发量，因为所有的
功能都在一起，无法准确预估扩容的服务器。
拆分：服务集群，充分利用服务器资源；现在只需要针对下单服务进行压测就可以得到，下单功能具体
能承受的并发量最高水位，从而更准确的进行扩容。

1.4. 隔离能力

服务之间调用做好隔离、容错、降级，可以避免出现级联错误

1.5. 维护能力

单体：随着业务量增加，应用慢慢膨胀，后续可能会变得牵一发而动全身，难以维护。
拆分：根据功能垂直拆分，责任更加分明，维护更加精准。
容错
单体：单点故障，一个功能 OOM 导致整个应用都不可用
拆分：弱依赖的服务出现故障，可以进行熔断（隔离）依然不影响主业务正常使用

1.6. 扩展

单体：难以技术升级
拆分：新的服务采用任意新技术（技术多样性）

1.7. 缺点

1.7.1. 分布式

分布式系统较难编程，因为远程调用速度很慢，并且总是面临失败的风险。对于开发人员的技术要求更高

1.7.2. 最终一致性

对于分布式系统而言，保持强一致性非常困难，这意味着每个人都必须管理最终一致性。

1.7.3. 运维复杂性

微服务必定带来开发、上线、运维的复杂度的提高，如果说单体应用复杂度为 10，实施了微服务后的复杂度将是 100，
配备了相应的工具和平台后，可以将复杂度降低到 50，但仍然比单体复杂的多。

1.7.4. 隐式接口

服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。

1.7.5. 重复劳动

在很多服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务
团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。

2. SOA、分布式、微服务之间有什么关系和区别

分布式架构是指将单体架构中的各个部分拆分，然后部署不同的机器或进程中去，SOA 和微服务基本上都是分布式架构的
SOA 是一种面向服务的架构，系统的所有服务都注册在总线上，当调用服务时，从总线上查找服务信息，然后调用
微服务是一种更彻底的面向服务的架构，将系统中各个功能个体抽成一个个小的应用程序，基本保持一个应用对应的一个服务的架构

3. 微服务怎么拆分

1、高内聚低耦合，职责单一，服务粒度适中，服务不要太细（有的团队甚至一个接口一个服务，一个表一个服务）
2、以业务模型切入：比如产品，用户，订单为一个模型来切入）
3、演进式拆分：刚开始不要划分太细，可以随着迭代过程来逐步优化。

微服务 1.0，仅使用注册发现，基于 SpringCloud 或者 Dubbo 进行开发，目前意图实施微服务的传统企业大部分处于这个阶段，或者正从单体应用，向这个阶段过渡，处于 0.5 的阶段；
微服务 2.0，使用了熔断，限流，降级等服务治理策略，并配备完整微服务工具和平台，目前大部分互联网企业处于这个阶段。传统企业中的领头羊，在做互联网转型的过程中，正在向这个阶段过渡，处于 1.5 的阶段；
微服务 3.0，Service Mesh 将服务治理作为通用组件，下沉到平台层实现，使得应用层仅仅关注业务逻辑，平台层可以根据业务监控自动调度和参数调整，实现 AIOps 和智能调度。目前一线互联网公司在进行这方面的尝试