微服务架构有哪些特点？
单体应用下的服务特性
每个文件都是一个可执行的文件，包含一个系统的所有功能，这些功能被打包成一体化的文件，几乎没有外部依赖，可以独立部署在装有Linux系统的硬件服务上
一个服务中包含了用户交互部分，业务逻辑处理层和数据访问层
单体应用架构下，一个服务中，两个业务模块作为该服务的一部分存在同一进程中，它们通过方法调用的方式进行通信
微服务架构下的服务特性
每个服务都只负责一小块儿具体的业务功能，能独立地部署到环境中，服务间边界相对清晰，相互间通过轻量级的接口调用或消息队列进行通信，为用户提供最终价值。这样的服务称为微服务（Microservice）。
对比总结：
微服务的缺点：
分布式特性：微服务系统通常也是分布式系统，那么在系统容错、网络延迟、分布式事务等方面容易产生各类问题，这也需要投入较多的人力物力去应对。
技术栈多样性：不同的组件选择不同的技术栈，会导致应用程序设计和体系结构不一致的问题，一定程度上也会产生额外的维护成本。
Dev-Ops：微服务架构下需要有一个成熟的 DevOps 团队来处理维护基于微服务的应用程序所涉及的复杂性，同时还需要配备相应的工具。
网络的可靠性：独立运行的微服务使用网络进行交互，这需要可靠且快速的网络连接，同时还需要避免服务间的网络通信存在安全漏洞。
从微服务数量规模角度来看。
线上运维方面：更多的服务意味着要投入更多的运维人力和物力，如服务器硬件资源、运行时容器、数据存储和带宽成本、人力维护成本、线上监控成本等。
团队协作成本：微服务之间主要通过接口进行通信，当修改某一个微服务的接口时，所有用到这个接口的微服务都需要进行调整，当核心接口调整时，工作量更为显著。
团队沟通成本：为了确保一个团队的服务发生更新时，不会破坏另一个团队的功能，就需要相关团队进行大量的沟通、确认工作。
微服务架构下的质量挑战
架构设计复杂度高；
团队协作难度大：系统依赖性的增加会给团队协作带来更大挑战，这里我所说的协作工作包括但不限于开发、联调、测试等。
1. 复杂的团队沟通：多个团队在使用，服务频繁进行改动或版本升级时，很容易出现跨微服务功能不可用、版本不兼容或延迟实现等问题
2、验证成本高：团队需要等待其他团队，以便完成相关微服务的并行开发；团队需要等待测试环境进行完整的搭建和配置后，方可实现整体联调、测试和验收。
3、反馈周期长：多团队并行开发，微服务由各自团队独立部署，测试环境的不稳定也更容易导致测试执行失败；服务较独立，有些链路很长的时候，定位问题复杂
测试成本高
1、测试环境：
某个微服务出问题时，导致其他服务不可用，谁来负责修复
2、测试技术和工具
微服务架构允许为每种服务使用不同的技术基础，可能导致需要使用不同工具来实现相同的功能，测试培养成本高
3、测试方法
测试对象发生非常多的变化，需要对测试对象进行重新分析
4、测试结果
微服务使用的是分布式系统，数据在网络上传输可能会出现不可避免的网络延时、超时、带宽不足等因素，会导致不稳定的测试结果
主要在：可靠性，数据一致性，关联性等方面