微服务简介与技术栈.docxVIP

微服务简介与技术栈 2021-12-25 这些年软件的设计规模越来越浩大，业务需求也越来越简单，针对系统的功能、高吞吐率、高稳定性、高扩展等特性提出了更高的要求。可以说业务需求是软件架构力量的第一推动力，由于这些因素导致了软件架构思想和相关技术也在发生着巨变。这些变化反应在软件架构行业里，就是我们开头越来越多的听到了很多新的词汇，比如：“分布式”、“SOA”、“微服务”、“大陆与台湾”等概念。 1 架构进展历程 现在的科学技术可以说是日新月异，进展快速。相对于我们软件设计行业也在发生着巨变，业务越来越简单，需求越来越浩大、繁杂，软件架构和部署的规模也发生着翻天覆地的变化，作为软件架构思想之一的“微服务架构”也在按着本人的规律进化着，接下来就简约的说说“微服务架构”进展经受的三个时期。 单体架构（Monolithic） 单体应用时代：应用程序无论如何分层，都是一个处理方案，或者说都是一个项目，这里的“处理方案”和“项目”不是我们使用的Visual Studio里面的概念，最终的程序代码都会在一个进程里运转。如图： 优点：开发简约，集中管理，没有分布式的损耗，都是系统进程内的通信。缺点：不好维护，升级困难，耦合严峻，无法应付高并发和大数据场景，无法快捷迭代。 只能接受同一种技术，很难用不同的言语或者相同言语不同版本开发不同模块。 系统耦合性太强，其中一个模块有问题，这个系统就会瘫痪，一个模块升级，整个系统就得停机维护。 要上线，必需一起上线，相互等待，无法快速相应市场需求。 集群负担大，假如想要集群，只能对整个系统进行集群，即便一个模块有压力。 垂直拆分 随着业务规模的越来越浩大，系统设计就越来越简单，大的系统就开头进行业务的垂直拆分。比如：有特地做商品秒宰的部门，有特地做生鲜商品的部门，有特地做超市的部门，等等，当然这是依据部门天生划分的，也有依据业务需求进行系统划分的。如图： 优点：垂直拆分，系统独立部署和维护，每个系统在本人进程内执行，分而治之。缺点：拆分越多，存储越简单，系统间反复的东西也越多，单个系统还是单体模式。 分布式服务 随着业务系统的越来越浩大，软件系统设计起来越来越简单。为了避开过度简单的业务需求，开头对业务系统的进行垂直拆分，构成多个独立的业务系统，假如多个系统之间要通信，可以通过跨进程的技术完成通讯。但是垂直拆分也导致了大量反复代码、反复模块的产生，比如：用户模块、日志模块、领取模块、认证授权模块等，这样分散的代码也给系统的维护和升级带来了困难。我们对业务重新划分，把独立的模块接口化、服务化，提高重用，这个时候，我们就开头进入了分布式服务的时代。（分布式的第一要务就是不要分布式）如图： 优点： 独立进程部署，独立进程运转，独立演化。服务之间可以做到高内聚，低耦合。 独立开发和维护，业务解耦，无论是业务系统还是分布式服务都独立演化。 分布式管理 隔离性添加 由一系列服务组装成系统，不用反复建设，模块、代码可以复用。 缺点： 数据全都性（多服务完成一个任务）和系统的可用性（集群）成为问题 数据库也进行了拆分 维护、设计、架构成本添加，调试、纠错更难 网络传输分布式损耗成本 不适合高并发和大数据的环境 微服务架构 微服务的消灭时分布式架构已经很成熟了，架构中各种问题已经有了很成熟的处理方案，对于现在的业务系统来说，分布式架构已经变成了一种常规手段，这个时候，微服务就消灭了。微服务架构是一个用分布式服务拆分业务规律，完成解耦的架构模式（架构风格）。微服务确定是分布式的一种，是在分布式技术成熟之后，然后把分布式当成解耦手段来架构系统——由于拆分的服务很细致，服务数量规模开头变多了，服务的体量开头缩小了，由以前几个大的服务，转变为多个独立运转的、原子性质的服务。如图： 微服务最重要的特性是： 可用性：描述一个系统在一段时间内供应有用资源的力量，从而削减停工时间，而保持其服务的高度可用性。 伸缩性：依据需求动态添加和删除系统中资源的力量，是水平或垂直扩展的特地实现。 集群（负载均衡）可以处理系统的高可用和伸缩特性。优点： 可以使用不同言语或者相同言语的不同版本开发各个模块。 系统耦合性低，各个模块分而治之，独立部署，独立发布，独立维护。 可以更快的相应市场的需求，更符合灵敏开发。 可以对不同模块使用集群策略，哪里有问题治哪里。 缺点： 开发难度更大，系统结构更简单。 运转效率低，网络调用成本很大。 SOA面对服务架构 Service-Oriented Architecture面对服务架构：是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。如图： 2 微服务架构的进展历程 我们要处理微服务的高可用和可伸缩的两个问题，自然就