微服务内功心法第一重：从何而来？由何而来？
大家好，欢迎来到程序视点！我是小二哥。
今天一起来记录下微服务的一些知识。正所谓“好记性，不如烂笔头”，以防自己忘记，也为以后可以查询。
当然，有很多东西也是参阅了其他大佬的总结和经验。这里做一些总结，配上自己的理解，分享给大家。
由于个人经验有限，可能会有一些有失偏颇的地方，当然希望有高手可以指正，不灵赐教，大家共同进步。（文末领取优惠福利）
简介
这些年软件的设计规模越来越庞大，业务需求也越来越复杂，针对系统的性能、高吞吐率、高稳定性、高扩展等特性提出了更高的要求。
可以说业务需求是软件架构能力的第一推动力，由于这些因素导致了软件架构思想和相关技术也在发生着巨变。这些变化反应在软件架构行业里，就是我们开始越来越多的听到了很多新的词汇，比如：“分布式”、“SOA”、“微服务”、“中台”等概念。
架构发展历程
现在的科学技术可以说是日新月异，发展迅速。相对于我们软件设计行业也在发生着巨变，业务越来越复杂，需求越来越庞大、繁杂，软件架构和部署的规模也发生着翻天覆地的变化，作为软件架构思想之一的“微服务架构”也在按着自己的规律进化着，接下来我们就简单的了解一下“微服务架构”发展经历的三个时期，这些只是个人理解。
1、单体架构（Monolithic）
单体应用时代：应用程序无论如何分层，都是一个解决方案，或者说都是一个项目。
这里的“解决方案”和“项目”不是我们使用的 Visual Studio里面的概念，最终的程序代码都会在一个进程里运行。如图：
优点：开发简单，集中管理，没有分布式的损耗，都是系统进程内的通信。
缺点：不好维护，升级困难，耦合严重，无法应付高并发和大数据场景，无法快捷迭代。 （1）、只能采用同一种技术，很难用不同的语言或者相同语言不同版本开发不同模块。 （2）、系统耦合性太强，其中一个模块有问题，这个系统就会瘫痪，一个模块升级，整个系统就得停机维护。 （3）、要上线，必须一起上线，互相等待，无法快速响应市场需求。 （4）、集群负担大，如果想要集群，只能对整个系统进行集群，即使一个模块有压力。
2、垂直拆分
随着业务规模的越来越庞大，系统设计就越来越复杂，大的系统就开始进行业务的垂直拆分。比如：有专门做商品秒杀的部门，有专门做生鲜商品的部门，有专门做超市的部门，等等，当然这是根据部门天生划分的，也有根据业务需求进行系统划分的。如图：
优点：垂直拆分，系统独立部署和维护，每个系统在自己进程内执行，分而治之。
缺点：拆分越多，存储越复杂，系统间重复的东西也越多，单个系统还是单体模式。
3、分布式服务
随着业务系统的越来越庞大，软件系统设计起来越来越复杂。为了避免过度复杂的业务需求，开始对业务系统的进行垂直拆分，形成多个独立的业务系统，如果多个系统之间要通信，可以通过跨进程的技术完成通讯。
但是垂直拆分也导致了大量重复代码、重复模块的产生，比如：用户模块、日志模块、支付模块、认证授权模块等，这样分散的代码也给系统的维护和升级带来了困难。
最终，我们对业务重新划分，把独立的模块接口化、服务化，提高重用，这个时候，我们就开始进入了分布式服务的时代。（分布式的第一要务就是不要分布式） 如图：
优点：
1、独立进程部署，独立进程运行，独立演化。服务之间可以做到高内聚，低耦合。
2、独立开发和维护，业务解耦，无论是业务系统还是分布式服务都独立演化。 3、分布式管理 4、隔离性增强 5、由一系列服务组装成系统，不用重复建设，模块、代码可以复用。
缺点：
1、数据一致性（多服务完成一个任务）和系统的可用性（集群）成为问题 2、数据库也进行了拆分。 3、维护、设计、架构成本增加，调试、纠错更难。 4、网络传输分布式损耗成本 5、不适合高并发和大数据的环境。
4、微服务架构
微服务的出现时分布式架构已经很成熟了，架构中各种问题已经有了很成熟的解决方案，对于现在的业务系统来说，分布式架构已经变成了一种常规手段，这个时候，微服务就出现了。
微服务架构是一个用分布式服务拆分业务逻辑，完成解耦的架构模式（架构风格）。微服务肯定是分布式的一种，是在分布式技术成熟之后，然后把分布式当成解耦手段来架构系统-----因为拆分的服务很细致，服务数量规模开始变多了，服务的体量开始缩小了，由以前几个大的服务，转变为多个独立运行的、原子性质的服务。如图：
微服务最重要的特性是： （1）、可用性：描述一个系统在一段时间内提供有用资源的能力，从而减少停工时间，而保持其服务的高度可用性。 （2）、伸缩性：根据需求动态添加和删除系统中资源的能力，是水平或垂直扩展的专门实现。 集群（负载均衡）可以解决系统的高可用和伸缩特性。
优点：
（1）、可以使用不同语言或者相同语言的不同版本开发各个模块。
（2）、系统耦合性低，各个模块分而治之，独立部署，独立发布，独立维护。
（3）、可以更快的响应市场的需求，更符合敏捷开发。
（4）、可以对不同模块使用集群策略，哪里有问题治哪里。
缺点：
（1）、开发难度更大，系统结构更复杂。
（2）、运行效率低，网络调用成本很大。
5、SOA 面向服务架构
Service-Oriented Architecture面向服务架构：是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。
如图：
三、微服务架构的发展历程
我们要解决微服务的高可用和可伸缩的两个问题，自然就会想到通过集群来实现，这个思路没有错。
如果我们实现了服务集群，那另外两个问题就会出现，这两个问题也导致了微服务架构的发展版本的差异。
第一个：服务的发现问题，调用方如何发现服务，有了新的服务，我们如何知道，有服务实例掉线，我们如何晓得，发现服务就很重要，这个是基础问题，第一个问题不解决，第二个问题也没有办法实现；
第二个：如何调用服务，如何管理那么多的服务实例。有那么多的集群实例，也就有那么多的服务实例，我们该怎么去调用这些服务呢？多个服务调用的关系如何呢？
由于这些问题，那我们就看看微服务架构的三个版本是如何解决的。
1、集中式代理----Nginx（V1.0 版本（服务注册/服务发现----手动））
（1）、服务发现，手动修改配置文件，重新启动。 （2）、负载均衡，可以轮训、权重、哈希等等。 （3）、服务新增无法发现，需要手动配置，服务掉线可以自动检查。 （4）、客户端的实现很简单，不需要额外的代码，简单，高效。
2、客户端嵌入----Consul（V2.0版本（服务注册/服务发现—自动---服务治理））
（1）、服务注册与发现，动态增加，自动完成。 （2）、健康检查，可以查看损坏服务，去掉服务，自动完成。
（3）、负载均衡，Consul 返回所有活动服务实例，客户端自己实现负载均衡。
功能强大，自动发现-自动下线，客户端集成比较复杂，负载均衡在客户端实现。
3、服务网格-Service Mesh（V3.0---技术不成熟，华为+唯品会，lstio）
SideCar服务管理服务实例的注册和发现，服务实例的治理和调用。Service Mesh’s Control Plan 管理所有的 SideCar。这个技术我就不多谈了，网上的资料也很多，目前这个技术还不是很成熟，使用的范围也不是很广，只有一些大的公司有过使用，比如：微软等。
最后
有关微服务的知识点非常的多。限于篇幅内容，今天先到这里。后续继续给大家分享更多的内容！