微服务的简介和技术栈

一、简介         这些年软件的设计规模越来越庞大，业务需求也越来越复杂，针对系统的性能、高吞吐率、高稳定性、高扩展等特性提出了更高的要求。可以说业务需求是软件架构能力的第一推动力，由于这些因素导致了软件架构思想和相关技术也在发生着巨变。这些变化反应在软件架构行业里，就是我们开始越来越多的听到了很多新的词汇，比如：“分布式”、“SOA”、“微服务”、“中台”等概念。        今天我就把我学习微服务的过程记录下来，包括所有技术的实现细节和个人的理解。俗话说：好记性，不如烂笔头，以防自己忘记，以后可以查询。当然，这些东西有很多东西都是自己的理解，里面的插图也是自己画的，可能会有一些有失偏颇的地方，当然希望有高手可以指正，不灵赐教，大家共同进步。

二、架构发展历程         现在的科学技术可以说是日新月异，发展迅速。相对于我们软件设计行业也在发生着巨变，业务越来越复杂，需求越来越庞大、繁杂，软件架构和部署的规模也发生着翻天覆地的变化，作为软件架构思想之一的“微服务架构”也在按着自己的规律进化着，接下来我们就简单的了解一下“微服务架构”发展经历的三个时期，这些只是个人理解。       1、单体架构（Monolithic）         单体应用时代：应用程序无论如何分层，都是一个解决方案，或者说都是一个项目，这里的“解决方案”和“项目”不是我们使用的 Visual Studio里面的概念，最终的程序代码都会在一个进程里运行。             如图：                   

            优点：开发简单，集中管理，没有分布式的损耗，都是系统进程内的通信。            缺点：不好维护，升级困难，耦合严重，无法应付高并发和大数据场景，无法快捷迭代。            （1）、只能采用同一种技术，很难用不同的语言或者相同语言不同版本开发不同模块。            （2）、系统耦合性太强，其中一个模块有问题，这个系统就会瘫痪，一个模块升级，整个系统就得停机维护。             （3）、要上线，必须一起上线，互相等待，无法快速相应市场需求。             （4）、集群负担大，如果想要集群，只能对整个系统进行集群，即使一个模块有压力。       2、垂直拆分        随着业务规模的越来越庞大，系统设计就越来越复杂，大的系统就开始进行业务的垂直拆分。比如：有专门做商品秒杀的部门，有专门做生鲜商品的部门，有专门做超市的部门，等等，当然这是根据部门天生划分的，也有根据业务需求进行系统划分的。             如图：                   

优点：垂直拆分，系统独立部署和维护，每个系统在自己进程内执行，分而治之。缺点：拆分越多，存储越复杂，系统间重复的东西也越多，单个系统还是单体模式。        3、分布式服务        随着业务系统的越来越庞大，软件系统设计起来越来越复杂。为了避免过度复杂的业务需求，开始对业务系统的进行垂直拆分，形成多个独立的业务系统，如果多个系统之间要通信，可以通过跨进程的技术完成通讯。但是垂直拆分也导致了大量重复代码、重复模块的产生，比如：用户模块、日志模块、支付模块、认证授权模块等，这样分散的代码也给系统的维护和升级带来了困难。我们对业务重新划分，把独立的模块接口化、服务化，提高重用，这个时候，我们就开始进入了分布式服务的时代。（分布式的第一要务就是不要分布式）           如图：                   

           优点：

  1、独立进程部署，独立进程运行，独立演化。服务之间可以做到高内聚，低耦合。 2、独立开发和维护，业务解耦，无论是业务系统还是分布式服务都独立演化。 3、分布式管理 4、隔离性增强 5、由一系列服务组装成系统，不用重复建设，模块、代码可以复用。          缺点：  1、数据一致性（多服务完成一个任务）和系统的可用性（集群）成为问题 2、数据库也进行了拆分。 3、维护、设计、架构成本增加，调试、纠错更难。 4、网络传输分布式损耗成本  5、不适合高并发和大数据的环境。         4、微服务架构        微服务的出现时分布式架构已经很成熟了，架构中各种问题已经有了很成熟的解决方案，对于现在的业务系统来说，分布式架构已经变成了一种常规手段，这个时候，微服务就出现了。微服务架构是一个用分布式服务拆分业务逻辑，完成解耦的架构模式（架构风格）。微服务肯定是分布式的一种，是在分布式技术成熟之后，然后把分布式当成解耦手段来架构系统-----因为拆分的服务很细致，服务数量规模开始变多了，服务的体量开始缩小了，由以前几个大的服务，转变为多个独立运行的、原子性质的服务。                如图：