微服务及技术栈介绍
简介
这些年软件的设计规模越来越庞⼤，业务需求也越来越复杂，针对系统的性能、⾼吞吐率、⾼稳定性、⾼扩展等特性提出了更⾼的要求。可以说业务需求是软件架构能⼒的第⼀推动⼒，由于这些因素导致了软件架构思想和相关技术也在发⽣着巨变。这些变化反应在软件架构⾏业⾥，就是我们开始越来越多的听到了很多新的词汇，⽐如：“分布式”、“SOA”、“微服务”、“中台”等概念。
今天我就把我学习微服务的过程记录下来，包括所有技术的实现细节和个⼈的理解。俗话说：好记性，不如烂笔头，以防⾃⼰忘记，以后可以查询。当然，这些东西有很多东西都是⾃⼰的理解，⾥⾯的插图也是⾃⼰画的，可能会有⼀些有失偏颇的地⽅，当然希望有⾼⼿可以指正，不灵赐教，⼤家共同进步。
架构发展历程
现在的科学技术可以说是⽇新⽉异，发展迅速。相对于我们软件设计⾏业也在发⽣着巨变，业务越来越复杂，需求越来越庞⼤、繁杂，软件架构和部署的规模也发⽣着翻天覆地的变化，作为软件架构思想之⼀的“微服务架构”也在按着⾃⼰的规律进化着，接下来我们就简单的了解⼀下“微服务架构”发展经历的三个时期，这些只是个⼈理解。
单体架构（Monolithic）
单体应⽤时代：应⽤程序⽆论如何分层，都是⼀个解决⽅案，或者说都是⼀个项⽬，这⾥的“解决⽅案”和“项⽬”不是我们使⽤的Visual Studio⾥⾯的概念，最终的程序代码都会在⼀个进程⾥运⾏。如图：
优点：开发简单，集中管理，没有分布式的损耗，都是系统进程内的通信。
缺点：不好维护，升级困难，耦合严重，⽆法应付⾼并发和⼤数据场景，⽆法快捷迭代。
•只能采⽤同⼀种技术，很难⽤不同的语⾔或者相同语⾔不同版本开发不同模块。
•系统耦合性太强，其中⼀个模块有问题，这个系统就会瘫痪，⼀个模块升级，整个系统就得停机维护。
•要上线，必须⼀起上线，互相等待，⽆法快速相应市场需求。
•集负担⼤，如果想要集，只能对整个系统进⾏集，即使⼀个模块有压⼒。
垂直拆分
随着业务规模的越来越庞⼤，系统设计就越来越复杂，⼤的系统就开始进⾏业务的垂直拆分。⽐如：有专门做商品秒杀的部门，有专门做⽣鲜商品的部门，有专门做超市的部门，等等，当然这是根据部门天⽣划分的，也有根据业务需求进⾏系统划分的。如图：
优点：垂直拆分，系统独⽴部署和维护，每个系统在⾃⼰进程内执⾏，分⽽治之。
缺点：拆分越多，存储越复杂，系统间重复的东西也越多，单个系统还是单体模式。
分布式服务
随着业务系统的越来越庞⼤，软件系统设计起来越来越复杂。为了避免过度复杂的业务需求，开始对业务系统的进⾏垂直拆分，形成多个独⽴的业务系统，如果多个系统之间要通信，可以通过跨进程的
技术完成通讯。但是垂直拆分也导致了⼤量重复代码、重复模块的产⽣，⽐如：⽤户模块、⽇志模块、⽀付模块、认证授权模块等，这样分散的代码也给系统的维护和升级带来了困难。我们对业务重新划分，把独⽴的模块接⼝化、服务化，提⾼重⽤，这个时候，我们就开始进⼊了分布式服务的时代。（分布式的第⼀要务就是不要分布式）如图：
优点：
•独⽴进程部署，独⽴进程运⾏，独⽴演化。服务之间可以做到⾼内聚，低耦合。
•独⽴开发和维护，业务解耦，⽆论是业务系统还是分布式服务都独⽴演化。
•分布式管理
•隔离性增强
•由⼀系列服务组装成系统，不⽤重复建设，模块、代码可以复⽤。
缺点：
•数据⼀致性（多服务完成⼀个任务）和系统的可⽤性（集）成为问题
•数据库也进⾏了拆分
•维护、设计、架构成本增加，调试、纠错更难
•⽹络传输分布式损耗成本
•不适合⾼并发和⼤数据的环境
分布式和微服务的关系
微服务架构
微服务的出现时分布式架构已经很成熟了，架构中各种问题已经有了很成熟的解决⽅案，对于现在的业务系统来说，分布式架构已经变成了⼀种常规⼿段，这个时候，微服务就出现了。微服务架构是⼀个⽤分布式服务拆分业务逻辑，完成解耦的架构模式（架构风格）。微服务肯定是分布式的⼀种，是在分布式技术成熟之后，然后把分布式当成解耦⼿段来架构系统——因为拆分的服务很细致，服务数量规模开始变多了，服务的体量开始缩⼩了，由以前⼏个⼤的服务，转变为多个独⽴运⾏的、原⼦性质的服务。如图：
微服务最重要的特性是：
•可⽤性：描述⼀个系统在⼀段时间内提供有⽤资源的能⼒，从⽽减少停⼯时间，⽽保持其服务的⾼度可⽤性。•伸缩性：根据需求动态添加和删除系统中资源的能⼒，是⽔平或垂直扩展的专门实现。
集（负载均衡）可以解决系统的⾼可⽤和伸缩特性。
优点：
•可以使⽤不同语⾔或者相同语⾔的不同版本开发各个模块。
•系统耦合性低，各个模块分⽽治之，独⽴部署，独⽴发布，独⽴维护。
•可以更快的相应市场的需求，更符合敏捷开发。
•可以对不同模块使⽤集策略，哪⾥有问题治哪⾥。
缺点：
•开发难度更⼤，系统结构更复杂。
•运⾏效率低，⽹络调⽤成本很⼤。
SOA⾯向服务架构
Service-Oriented Architecture⾯向服务架构：是⼀个组件模型，它将应⽤程序的不同功能单元（称为服务）进⾏拆分，并通过这些服务之间定义良好的接⼝和协议联系起来。如图：
微服务架构的发展历程
我们要解决微服务的⾼可⽤和可伸缩的两个问题，⾃然就会想到通过集来实现，这个思路没有错。
如果我们实现了服务集，那另外两个问题就会出现，这两个问题也导致了微服务架构的发展版本的差异。第⼀个：服务的发现问题，调⽤⽅如何发现服务，有了新的服务，我们如何知道，有服务实例掉线，我们如何晓得，发现服务就很重要，这个是基础问题，第⼀个问题不解决，第⼆个问题也没有办法实现；第⼆个：如何调⽤服务，如何管理那么多的服务实例。有那么多的集实例，也就有那么多的服务实例，我们该怎么去调⽤这些服务呢？多个服务调⽤的关系如何呢？
由于这些问题，那我们就看看微服务架构的三个版本是如何解决的。
集中式代理——Nginx V1.0版本（服务注册/服务发现——⼿动）
•服务发现，⼿动修改配置⽂件，重新启动。
•负载均衡，可以轮训、权重、哈希等等。
•服务新增⽆法发现，需要⼿动配置，服务掉线可以⾃动检查。
•客户端的实现很简单，不需要额外的代码，简单，⾼效。
•客户端的实现很简单，不需要额外的代码，简单，⾼效。
客户端嵌⼊——Consul V2.0版本（服务注册/服务发现——⾃动——服务治理）
•服务注册与发现，动态增加，⾃动完成。
•健康检查，可以查看损坏服务，去掉服务，⾃动完成。
•负载均衡，Consul返回所有活动服务实例，客户端⾃⼰实现负载均衡。
功能强⼤，⾃动发现-⾃动下线，客户端集成⽐较复杂，负载均衡在客户端实现。
服务⽹格——Service Mesh V3.0——技术不成熟，华为+唯品会，Istio
SideCar服务管理服务实例的注册和发现，服务实例的治理和调⽤。Service Mesh’s Control Plan管理所有的SideCar。这个技术我就不多谈了，⽹上的资料也很多，⽬前这个技术还不是很成熟，使⽤的范围也不是很⼴，只有⼀些⼤的公司有过使⽤，⽐如：微软等。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。