1、微服务是什么？

1.1微服务定义

       依稀记得应该是在2017年的时候，一个叫微服务的词经常出现在同事嘴中，那时网络中对于微服务的概念都比较模糊。
       我们可以先来看看维基百科是如何定义微服务的：
       一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。

乍一看我们还是无法理解到底什么是微服务，下面我会通过微服务的发展历程，带大家了解一下。

2、单体架构

2.1、单体架构应用技术

       在早期，互联网中应用技术栈大致有两种： LNMP（Linux + Nginx + MySQL + PHP）和 MVC（Spring + iBatis/Hibernate + Tomcat）两大分支。都为单体架构。语言太过苍白，直接上单体架构图：

2.2、单体架构图

单体架构图如下：

2.3、单体架构中的问题

       在程序刚开始的时候，应用的⽤户量、数据量规模都⽐较⼩，项⽬所有的功能模块都放在⼀个⼯程中编码、编译、打包并且部署在⼀个Tomcat容器中的架构模式就是单体应⽤架构，这样的架构既简单实 ⽤、便于维护，成本⼜低，成为了那个时代的主流架构⽅式。
       然而随着业务规模的不断扩大，团队开发人员的不断扩张，单体应用架构就会开始出现问题。我估计经历过业务和团队快速增长的同学都会对此深有感触。从我的角度来看，大概会有以下几个方面的问题。
       部署效率低下。以我实际参与的项目为例，当单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次，甚至需要 10 分钟以上。这也经常被新加入的同事吐槽说，部署测试一次的时间，都可以去楼下喝杯咖啡了。
       团队协作开发成本高。以我的经验，早期在团队开发人员只有两三个人的时候，协作修改代码，最后合并到同一个 master 分支，然后打包部署，尚且可控。但是一旦团队人员扩张，超过 5 人修改代码，然后一起打包部署，测试阶段只要有一块功能有问题，就得重新编译打包部署，然后重新预览测试，所有相关的开发人员又都得参与其中，效率低下，开发成本极高。
       系统高可用性差。因为所有的功能开发最后都部署到同一个 WAR 包里，运行在同一个 Tomcat 进程之中，一旦某一功能涉及的代码或者资源有问题，那就会影响整个 WAR 包中部署的功能。比如我经常遇到的一个问题，某段代码不断在内存中创建大对象，并且没有回收，部署到线上运行一段时间后，就会造成 JVM 内存泄露，异常退出，那么部署在同一个 JVM 进程中的所有服务都不可用，后果十分严重。
       线上发布变慢。特别是对于 Java 应用来说，一旦代码膨胀，服务启动的时间就会变长，有些甚至超过 10 分钟以上，如果机器规模超过 100 台以上，假设每次发布的步长为 10%，单次发布需要就需要 100 分钟之久。因此，急需一种方法能够将应用的不同模块的解耦，降低开发和部署成本。
我们看看单体架构的优缺点：

2.4、单体架构优点

• 项⽬前期开发节奏快，团队成员少的时候能够快速迭代
• 架构简单：MVC架构，只需要借助IDE开发、调试即可
• 易于测试：只需要通过单元测试或者浏览器完成
• 易于部署：打包成单⼀可执⾏的jar或者打成war包放到容器内启动

2.5、单体架构缺点

• 随着时间推移业务增加，功能不断迭代，项目会不断变得臃肿，业务耦合严重，随着项目团队增大，沟通成本高，项目启动慢
• 新增业务困难：在已经乱如麻的系统中增加新业务，维护旧功能，⼀脚踩进去全是不可预测 的问题。新⼈来了以后很难接⼿任务，学习成本⾼
• 核⼼业务与边缘业务混合在⼀块，出现问题互相影响

3、垂直架构

3.1、垂直架构应用技术

       为了避免单体架构上出现的那些问题，大家开始对应用按照业务做垂直划分，把原来的的一个单体架构拆成一堆单体应用，这时候就由原来的单应用变成了多应用部署，这就是垂直架构。
垂直架构实际只是把一台主机扩容至多台，把服务分流，进行负载均衡，把不同系统的数据分开存储，并且使用数据库集群，进行数据的分流。

3.2、垂直架构图

垂直架构图如下：

3.3、垂直架构中的问题

       在实际应用中，当后端主机的IP地址发生变化时，如果没有在负载均衡上面及时更改，那会引起生产事故，而每次IP发生变化都需要手动去修改IP地址。这样在后期发布频繁的时候，会占用大量的时间和出错的概率。
       监控在当时好多功能并没有，导致不能监控到很多数据，包括：调⽤的成功率、失败率、总耗时等。会让后期的维护变得艰难。

3.4、垂直架构优点

• 系统拆分实现了流量分担，解决了并发问题
• 可以针对不同模块进⾏优化
• ⽅便⽔平扩展，负载均衡，容错率提⾼
• 系统间相互独⽴，互不影响，新的业务迭代时更加⾼效

3.5、垂直架构缺点

• 服务之间相互调⽤，如果某个服务的端⼝或者ip地址发⽣改变，调⽤的系统得⼿动改变（也就是硬编码）
• 搭建集群之后，实现负载均衡⽐较复杂，如：内⽹负载，在迁移机器时会影响调⽤⽅的路 由，导致线上故障
• 服务之间调⽤⽅式不统⼀，基于 httpclient 、 webservice ，接⼝协议不统⼀
• 服务监控不到位：调⽤的成功率、失败率、总耗时等等这些监控指标是没有的

4、SOA架构

4.1、SOA应用技术

       SOA (Service-Oriented Architecture)，即⾯向服务的架构。其思想就是根据实际业务，把系统拆分成合适的、独⽴部署的模块，模块之间相互独⽴（通过Webservice/Dubbo等技术进⾏通信）。可以理解为拆分出来的每个系统都是一个个的组件，组件与组件之间都是通过服务进行调用。

4.2、SOA架构图

SOA架构图如下：

4.3、垂直架构中的问题

       在使用SOA架构的过程中发现，SOA中的协议类型比较多，维护的时候很困难。
       由于SOA架构中并没有单独对服务拆分的细粒度进行规定，以至于在实际应用中，有的服务拆分较大，有的拆分较小，给后期的项目管理带来的很大的麻烦。
       数据都存储再同一个数据库中，即使使用了集群模式，但是当访问量大的时候，还是会导致各个模块数据之间相互影响。可能会导致返回时间过长，超时等问题。其中一个模块数据量大，会影响其他模块数据的读写性能。
       在做了垂直划分以后，模块随之增多，维护的成本在也变⾼，⼀些通⽤的业务和模块重复的越来越多，为了解决垂直应用上出现的那些问题如：接⼝协议不统⼀、服务⽆法监控、服务的负载均衡等阿里巴巴搞了一个高效的JavaRpc框架（仅仅是soa架构框架的一个代表）Dubbo，它提供了三⼤核⼼能⼒：⾯向接⼝的远程⽅法调⽤，智能容错和负载均衡，以及服务⾃动注册和发现。

4.4、垂直架构优点

• 分布式
• 松耦合
• 扩展灵活
• 可重⽤

4.5、垂直架构缺点

• 服务抽取粒度较⼤
• 服务调⽤⽅和提供⽅耦合度较⾼（接⼝耦合度）

5、微服务架构

5.1、微服务应用技术

       所谓微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，每个小服务运行在自己的进程中，并以轻量级的机制（通常是HTTP RESTful API）的方式进行通信，这些服务围绕着业务能力所建立的，并且可以由完全自动化的部署机构独立部署，这些服务的集中管理只有最低限度，可以用不同的编程语言编写并使用不同的数据库存储技术。

5.2、微服务架构图

微服务架构图如下：

5.3、微服务架构中的问题

       在项目中模块化是我们在做软件设计时很重要的方式。模块化带来高内聚、低耦合，提升重用能力。随着系统的演化，我们会产生各种类库、组件来实现模块化，并且能在跨团队之间实现重用。
       微服务则是以服务的形式，在更高的层面实现模块化，各个团队各自独立开发与维护自己的服务，并提供给其他团队使用。有着清晰的边界。
       每一个模块都可以单独部署，不受约束，不需要其他部门或团队参与，在出问题时，定位问题比较及时。减少服务异常带来的损失。
       微服务是分散式治理，不存在集中式管理的问题。各个团队可以按照自己擅长的技术栈来提供微服务，对于微服务的使用方来讲，根本不需要关注提供方的技术栈。尽管微服务可以兼容不同的技术栈，但在公司内或者一个大部门内还是建议尽量统一技术栈，可以在一定程度上减少成本。

5.4、微服务架构优点

• 服务的独立部署
• 服务的快速启动
• 更加适合敏捷开发
• 职责专一，由专门的团队负责专门的服务
• 服务可以动态按需扩容
• 代码的复用

5.5、微服务架构缺点

• 分布式部署，调用的复杂性高
• 独立的数据库，分布式事务的挑战
• 测试的难度提升
• 运维难度的提升

5.6、微服务架构四个核心问题及解决办法

5.6.1、问题1、服务多，客户端该怎么访问？

解决办法：

• Api网关，zuul组件
• Feign—HttpClient—Http，同步并阻塞
• 服务注册和发现，Eureka
• 熔断机制，Hystrix

5.6.2、问题2、这么多服务，服务之间如何通信？

解决办法：

• 没有API ，要么需要使用第三方实现，或者自己去实现
• 使用Dubbo框架，Dubbo一个高性能基于Java的RPC通信框架
• 服务注册与发现，Zookeeper
• 没有熔断

5.6.3、这么多服务，如何治理？

解决办法：

• 使用SpringCloud Alibaba可以解决

5.6.4、服务挂了怎么办？

解决办法：

• 使用服务网格（istio），下一代微服务标准，Server Mesh。

6、总结

即使微服务也有缺点，但是没有哪一款软件或者架构是十全十美的，他给我们带来的便利是大于弊端的。
这种架构使我们最开始的只能支持非常少量的用户访问量，到现在十万，百万，千万量的访问，是一个巨大的进步。
本人使用阿里云和腾讯云比较少，使用华为云比较多，感兴趣的同学可以去华为云的官网上看看有一个叫做Servicestage的服务，我觉得这比较接近云原生的真实模型，他里面包括DevOps，与云容器集成，服务注册中心，服务配置中心，限流熔断，服务链监控，API网关，负载均衡，容错限流，监控告警。大家感兴趣可以去看看。