慢慢来比较快，虚心学技术
原文链接（欢迎造访，多多支持）：https://www.yuque.com/keep_zero/spring_cloud/kiis1m
什么是微服务？
微服务强调的是服务的大小，关注于某一个点，是具体解决一个问题或提供落地对应服务的一个服务应用。
换句话说，微服务就是将传统的一站式应用，根据业务拆分成一个个的服务，每个微服务提供单个业务功能，彻底解耦。
什么是微服务架构？
简单地说，微服务架构是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务****，这些小型服务都在各自独立的****进程中****运行，服务之间通过基于 HTTP的 RESTflul API 进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写
微服务架构演变
微服务架构演变过程：单体架构——>垂直架构——>分布式架构——>SOA面向服务架构——>微服务架构
单体架构
特点:
1、所有功能集中在一个应用中（称为单体应用）
2、部署时打包成一个归档包（war包）部署到服务器中
3、通过集群（session共享）的方式提高性能
4、此时的****数据访问框架（ORM，用于简化数据库操作）是关键
类比场景：王麻子一个人开的小饭馆，一个人即做厨师，又做服务员，还做财务（虽然是小饭馆）
优点：
项目架构简单，前期开发成本较低，周期较短，适合小型项目
缺点：
1、维护成本较高，所有功能集中在一个工程，耦合性非常高
2、系统性能扩展通过扩展集群节点实现，成本太高
3、技术栈受限，整体应用必须使用统一语言及技术。
应用场景：业务场景简单,网站流量很小，投入开发人员数量不多
垂直架构
当访问量增大，单一应用增加机器带来的加速度逐渐减少，遂将应用划分为几个互不相干的应用
特点：
1、将单体架构的系统应用根据业务划分出互不相干的独立子系统
2、各子系统间通过接口调用的方式进行交互
3、用于加速前端开发的****Web框架是关键
类比场景：随着生意日渐火爆，王麻子后面忙不过来了，就请了几个伙计，一个负责厨房，一个负责传菜，一个负责下订单，王麻子负责去采购，当然了，王麻子有小媳妇儿了，小媳妇儿负责餐馆的财务收支，这样子，整个餐馆的运营瞬间清晰了起来，如果哪一部分人手不够仅仅需要添加该部分的人手即可。
优点：
1、系统拆分实现了流量分担，解决并发问题
2、可以针对单个模块功能进行优化，且各子系统或模块可以使用不同的技术
3、方便对系统进行水平扩展，负载均衡
缺点：
1、服务之间通过接口相互调用，其中某个子系统的接口IP变更后，调用的系统需要手动更改
2、搭建集群后，实现负载均衡的参考会更加复杂
3、数据同步问题，由于使用不同的数据库，数据库之间会存在共同冗余信息需要同步（可能存在大量重复性代码，如上述的订单功能）
应用场景：访问量较大，高并发情况，且子系统间交互不多
分布式架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的基础服务中心，使前端应用能快速响应市场需求
特点：
1、将垂直架构中的应用核心业务抽取出来作为基础服务中心
2、各业务系统调用基础服务中心，避免业务系统间的互相调用。
3、此时，用于提高业务服务与整合的****分布式服务架构（RPC）是关键
类比场景：生意一天天越来越好，店小二也从当初的一个变成了多个，餐馆的菜式并不再局限于一种，所以招聘了好几个厨师分别做川菜、粤菜、湘菜、苏菜,且采购也从当初的王麻子变成三个人，当然，财务就由王麻子和他媳妇儿管了，也是美滋滋。那么由于生意好了，订单自然也就多了，而且订单五花八门，人手去记录自然是慢的不行了，王麻子就采购了一个点单机和采购机，联通餐馆前台和后台，避免了中间的口头传达错误
优点：
1、将基础服务抽取出来作为独立服务，各应用直接调用，提高了代码复用和开发效率
2、各子系统之间相互解耦，容错率提高
缺点：
1、业务系统和基础服务系统间耦合度增加，调用复杂，难以维护
2、搭建集群之后，负载均衡难以实现
应用场景：访问量较大，高并发情况，且子系统间交互复杂
SOA面向服务架构（Service Oriented Architecture,服务治理）
当服务越来越多，需要管理的地址也会越来越多，依赖关系越来越复杂，服务状态难以管理（某个服务宕掉还得去排查才会发现），且小服务带来的资源浪费也是越来越明显，此时需要一个调度中心和资源管理中心基于访问压力实时管理集群容量，提升集群利用率
特点：
1、服务注册中心，实现服务自动注册与发现，无需人为记录服务地址（像是字典）
2、服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
3、动态监控服务状态
4、SOA通过称为数据总线ESB的中间组件进行系统之间的交互控制
5、用于提高机器利用率的 资源调度和治理中心(SOA) 是关键
类比场景：王麻子的餐馆越来越大，也越来越忙,后厨也从当初的四大菜系发展到了八大菜系，人员剧增，各部门之间的交流日渐困难，如厨房八大菜系要叫采购部门采购的材料五花八门，有时候还找不到对应的人；订单错误也找不到人对应负责。所以王麻子又创建了后勤管理部，统一管理后勤调配和业务，增减各部门人员等，厨师和采购，财务等部门之间的交流不再是直接交流，解决了先前所有人交流混乱的问题
优点：
1、服务调用透明化，服务间不需要知道服务的具体地址，无需关心其依赖关系
2、SOA会监控各个服务的运行状态，一旦发生服务状态变更可以立马发现
3、数据总线可以动态控制各服务集群容量大小，提高集群利用率
4、每个服务都可以使用自己的技术，只需要统一接口即可
缺点：
1、可靠性，SOA架构没有为服务间调用的事务一致性做好准备
2、复杂性，提升了整体应用的复杂性，服务之间调用通过http协议交互，增加了性能消耗
3、由于复杂性带来的负载均衡困难问题，因为服务间的依赖关系变复杂了
应用场景：访问量较大，高并发情况，且子系统间交互复杂，要求提高机器利用率
微服务架构
SOA架构虽然确保了应用能够交互操作,但是每个应用依旧是一个大的体系，难以扩展，且应用与应用之间的依赖性太强，而微服务架构更注重组件化和去中心化思想。将系统分为更细的独立的服务，而且每个服务独立自治，拥有自己独立的数据库和逻辑功能，服务与服务之间互不相关,一个服务的崩溃并不影响别的服务运行，每个服务提供Rest API，统一通过API网关向外提供接口访问。
特点：
1、纵向划分体系，每一个体系都是完整独立的应用
2、去中心化，每个微服务有自己的数据库，且不能访问其他服务的数据库
3、组件化，开发者不需要协调其他服务部署对本服务的影响
类比场景：王麻子的餐馆越做越大，但是由于所有菜系都集中在一家店里，就会有很多不同地域爱好的人来就餐，那么，有时候一个季度可能其中几个菜系点的人很多，其他菜系点的少，就会造成人员闲着，而且各地域的客户就餐习惯迥异，统一服务就很有可能发生冲突（“打起来都有可能”）。王麻子打算开分店，每个分店负责不同菜系的供应，互不干扰，且拥有自己完整的一个经营体系，每个季度根据火爆程度对分店数量进行调控，比如川菜店生意更火，则多开几家，鲁菜店生意惨淡，则收拾几家。还可能扩展出西餐、日料、韩料等餐厅，灵活可控。自此，王麻子和小媳妇儿在大江南北逍遥快乐。。。。。
优点：
1、技术异构性，微服务可以轻松采用不同的技术栈。
2、容错性，一个服务不可用不会导致整个系统不可用
3、可扩展性，可以单独对某个服务进行功能扩展
4、简化部署，每次部署仅需部署部分服务，而不是全盘部署
缺点：
1、当服务数量增加，管理维护成本上升
2、兼具分布式本身的复杂性
3、接口调整的成本上升，某个微服务的接口经过调整，可能多个调用该接口的微服务需要同时更改
4、重复劳动，如在某个微服务的工具类在别的服务也需要使用，但是又不可以直接调用，就需要在每一个微服务上都创建这么一个工具类，造成代码重复。
应用场景：访问量较大，功能模块数量较多，调用依赖关系复杂。
常用微服务框架：Dubbo（阿里,JAVA），Motan（微博,JAVA）、Tars（腾讯，C++）,SpringCloud（Pivotal公司，JAVA）
总结
1、微服务架构是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于 HTTP的 RESTflul API 进行通信协作
2、微服务架构的演进历史：单体架构——>垂直架构——>分布式架构——>SOA面向服务架构——>微服务架构
3、架构演进的过程，也是系统不断细化控制和开发，提高灵活性和抗风险性的过程，应了设计模式的理念：****天下大道，分之合之
参考文章：
https://blog.csdn.net/qq_41531324/article/details/80806168
https://www.cnblogs.com/lonelyxmas/p/10495705.html
https://msd.misuland.com/pd/2884250137616453946
https://blog.csdn.net/HistoryCreator/article/details/89059711
https://cloud.tencent.com/developer/article/1378077
如有贻误，还请评论指正
点击关注，持续更新哦
