什么是微服务体系结构？
微服务体系结构通常是体系结构模型或体系结构风格。
它提倡将单个APP应用程序划分为较小的服务组，在每个服务执行各自独立的流程过程中，服务之间相互协调、协作，为用户提供最终价值。
服务之间使用轻量级的通信机制相互交流。 通常是基于HTTP的rest风格的API。 每项服务都围绕特定业务构建，可以独立部署到生产环境、同类生产环境等。
微服务体系结构和单体体系结构的区别
单体架构
通常，" monolith application "是指将APP应用程序的所有功能(包括JAR、EXE、cmdbm或其他归档格式)打包到一个独立的单元中。
单体应用具有以下优点。
开发简单直接，集中管理，几乎没有重复开发
所有功能都是本地的，没有分布式的管理开销和调用开销
其缺点也很明显，特别是对互联网公司来说：
开发效率低下：所有开发都在一个项目中更改代码，传递代码互相等待，代码冲突不断
代码很难维护：代码功能结合在一起，新人不知道从哪里着手
部署不灵活：需要时间进行构建，小的更改需要重建整个项目，这个过程往往很长
不稳定：由于一些小问题，整个APP应用程序可能挂起
可扩展性不足：无法满足高度并发的业务需求
微服务架构
随着业务需求的快速变化，灵活性、灵活性和可扩展性的需求不断提高，迫切需要更快、更高效的软件交付方法。 微服务是满足这一需求的软件体系结构的风格。 单个APP应用程序分解为多个更小的服务，每个服务都有自己的归档文件，单独部署并组成一个APP应用程序。 这里的“微”是指服务的范围仅限于各个功能，而不是代码的行数。
微服务具有以下优点：
微服务是松藕的，无论是开发阶段还是引进阶段都是独立的。
快速响应，易于局部修改，即使一个服务出现问题也不会影响整个APP应用程序。
易于与第三方APP应用程序系统集成，支持不同语言的开发，并利用最新技术的集成。
各项微服务小，充分凝聚，足够小，代码容易理解。 团队可以更加关注自己的工作成果，专注于指定的业务功能和业务需求。
开发简单，开发效率提高，一项服务只针对一件事，小团队可能可以单独开发。 这个小团队可以由2到5个开发人员组成。
同样，还有以下缺点：
微服务架构可能会带来过多的运输业务，需要团队具备一定的DevOps技术。
分布式系统可能很复杂，很难管理。 因为分散配置跟踪的问题很难。 服务数量的增加会增加管理的复杂性。
微服务体系结构的主要特征
微服务体系结构是松散耦合、具有一定有界上下文的面向服务的体系结构。 这意味着，如果发生功能更改，但需要同时修改所有服务，则它们并不是微服务。 要说为什么，那是因为它们紧密地结合在一起。 如果需要了解服务的上下文场景的使用条件，那就是有上下文边界的服务。 这个定义一般来自域驱动设计(DDD )。
其主要特点是组件化、松散耦合、自治、去中心化，表现在以下几个方面：
的细分服务要细分，服务粒度要小，但每项服务都是单一职责业务能力的封装，集中在一件事上。
独立部署和扩展，每个服务独立部署并在一个流程中运行。 这种操作和部署方法为系统提供了灵活的代码组织方法和发布空间，并允许快速交付和响应变化。
独立开发进化，技术选型灵活，不受遗留系统的技术约束。 选择合适的业务问题合适的技术可以独立进化。 在服务和服务之间采用与语言无关的API进行整合。 相对于单体体系结构，微服务体系结构是一种更加面向业务创新的体系结构模式。
独立的团队和自治、团队负责整个服务生命周期，在独立的上下文中工作，不需要统一的指挥中心，自己决策和管理。 和队伍之间由松散的社区部落联系在一起。
通过解除我们所做的事情的连接，分开治疗，不减少
必要的损耗，使得整个复杂的系统和组织能够快速的应对变化。需要考虑的问题
单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。
单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。
单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。
多个相同的微服务可以做负载均衡，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。
微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。
还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。
选择微服务框架的关注点
服务注册、发现、负载均衡和健康检查，假定采用进程内LB方案，那么服务自注册一般统一做在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。
监控日志，框架一方面要记录重要的框架层日志、Metrics和调用链数据，还要将日志、Metrics等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。
REST/RPC和序列化，框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来，HTTP/REST是当前主流API暴露方式，在性能要求高的场合则可采用Binary/RPC方式。针对当前多样化的设备类型(浏览器、普通PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出Ajax友好的JSON消息格式，而对内部服务及应用程序，框架支持输出性能高的Binary消息格式。
配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。
限流和容错，框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。
管理接口，框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。
统一错误处理，对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。
安全，安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。
文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用API的开发和测试人员带来极大便利。Swagger是一种流行Restful API的文档方案。
一个完整的微服务系统，它最少要包含以下功能：
日志和审计，主要是日志的汇总，分类和查询
监控和告警，主要是监控每个服务的状态，必要时产生告警
消息总线，轻量级的MQ或HTTP
注册发现
负载均衡
部署和升级
事件调度机制
以下功能不是最小集的一部分，但也应该在选择时进行考虑：
认证和鉴权
多语言支持, 是否支持多种编程语言
统一服务构建和打包
统一服务测试
统一配置文件管理
服务依赖关系管理
问题跟踪调试框架
灰度发布
蓝绿部署
资源管理，如：底层的容器, 虚拟机, 物理机和网络管理
开发方式影响
随着持续交付概念推广以及容器概念的普及，微服务将这两种理念和技术结合起来，形成新的微服务+API+容器平台的开发模式，提出了容器化微服务的持续交付概念。
下图为传统单体应用的DevOps开发队伍方式：
这种整体型架构要求产品队伍横跨产品管理 Dev开发 QA DBA 以及系统运营管理，而微服务架构引入以后，如下图：
微服务促进了DevOps方式的重组，将一个大臃肿的整体产品开发队伍切分为根据不同微服务的划分的产品队伍，以及一个大的整体的平台队伍负责运营管理，两者之间通过API交互，做到了松耦合隔绝。
微服务的实施是有一定的先决条件：基础的运维能力（如监控、快速配置、快速部署）需提前构建，否则就会陷入较被动的局面。推荐采用CI/CI改进基础设施及运维的实践，通过自动化运维使得可以快速安全的响应和处理微服务对服务部署的要求，通过容器技术保证服务环境之间拥有更高的一致性，降低“在我的环境工作，而你的环境不工作”的可能，也是为后续的发布策略和运维提供更好的支撑。
想要更好的实施微服务, 首先需要考虑构建团队DevOps能力，这是保证微服务架构在持续交付和应对复杂运维问题的动力之源。
其次保持服务持续演进，使之能够快速、低成本地被拆分和合并，以快速响应业务的变化；同时要保持团队和架构对齐。微服务看似是技术层面的变革，但它对团队结构和组织文化有很强的要求和影响。识别和构建匹配架构的团队是解决问题的另一大支柱。
最后，打造持续改进的组织文化是实施微服务的关键基石。只有持续改进，持续学习和反馈，持续打造这样一个文化氛围和团队，微服务架构才能持续发展下去，保持新鲜的生命力，从而实现我们的初衷。
原文链接：https://blog.csdn.net/kunyus/article/details/90670710
—————END—————
推荐阅读
干货|如何步入Service Mesh微服务架构时代
实战|Service Mesh微服务架构实现服务间gRPC通信
再见Nacos，我要玩Service Mesh了！
Kubernetes微服务自动化发布系统
Kubernetes微服务监控体系
Kubernetes学习环境难搭建？Mac笔记本上安装一个！