微服务架构浅说
在说微服务架构之前，先简单了解一下传统单应用开发的一些优缺点。
单体应用
什么是单体应用？
单体应用就是在web服务器运行的一个war包含了所有的业务功能。
单体应用的优点？
-
部署简单：因为只需要停止web服务器，并将war进行覆盖即可。
-
方便测试：只需要访问一个web页面即可进行web测试
-
便于运行错误的排查：因为所有的访问都会在一个web服务器进行，那么对日志的查看，问题的排查带来天然的便捷性。
单体应用的缺点？
-
维护差（文件多）：随着业务的增长，业务代码的增加，会形成成千上万的源码文件。类间的耦合性强。
-
扩展性差（复杂性高、耦合性强，更新技术困难）：当有更好的技术框架出现的时候，无法快速的进行技术堆栈的切换。因为单体应用的技术架构会应用在业务模块，耦合性高，改动的代价非常巨大，甚至是牵一发而动全身（技术债）。
-
构建（编译）缓慢：随着代码堆积的越多，编译器编译时间会越来越长。笔者曾经编译了一个多小时。
-
部署缓慢：随着war越来越大（启动加载的类越来越多），web服务器中启动war应用，会耗费更多的时间来启动。笔者曾经部署启动了十几分钟啊
-
低可用：一旦服务出现OOM，或者服务宕掉，将影响整个业务系统。
可以看出单体服务的缺点还是蛮多的：不易扩展、压制技术创新、构建部署困难等。那么有什么办法可以解决这些问题吗？答案是有的，那就是微服务架构！
微服务架构
什么是微服务架构？
微服务架构（即大家所说的微服务）是指开发应用所用的一种架构形式。 通过微服务，可将大型应用分解成多个独立的组件，其中每个组件都有各自的责任领域。在处理一个用户请求时，基于微服务的应用可能会调用许多内部微服务来共同生成其响应。
每个服务可以作为单独的一个应用程序进行运行（部署），有自己业务逻辑，API接口，数据存储等。也可以简单的说，将原有的我们传统开发的单体应用，进行领域（模块）划分，将业务服务进行更加细粒度的划分，然后进行开发，打包成一个个可以独立运行的服务（jar或war文件），供其他服务调用或者供前端（客户端）调用。
代码的世界里是没有银弹的。任何技术/架构都有其优点和缺点。下面将介绍使用微服务架构时，微服务架构给我们带来的优缺点：
微服务的优点？
-
便于开发、维护：一般一个微服务只会关注一个特定的业务功能，所有微服务的业务功能划分更加细，所涉及的领域模块更清晰。对于设计、开发和维护都相对简单。
-
部署启动快：因为单个微服务的代码相对较少，所需要加载的类也就相对少，那么服务启动的时间肯定也会相对快很多。
-
容错高：当某个微服务需要进行升级更新或者宕掉后，可以通过熔断、降级的机制，不影响其他业务的正常访问。
-
技术栈不受限：在微服务架构中，可以采用不同的编程语言，不同的技术架构进行开发。比如：某些服务可以使用java进行开发；某些服务可以采用PHP、Go、Nodejs开发等等
微服务的缺点？
-
技术栈涉及很广：要处理服务间的通信，健康状态监测；要对服务链进行熔断、降级；对消息进行分布式处理；会话分布式处理；事务分布式处理等等
-
运维维护难度大：将一个单体应用分解成多个微服务，运维上，无论是物理机的管理，还是服务的开启都比原来的单体应用要复杂
-
问题排查难度大：由于服务数量众多，相互调用，一旦服务链出现问题，运维人员或开发人员排查就变得复杂。
-
测试难度大：服务间相互调用，必须保持服务链路畅通或者要得到在每个服务结点降级结果，使得测试难度变得复杂。
-
接口调整代价成本大：微服务之前通过接口进行通信，那么一旦需要修改某一个微服务的API，那么所有使用了该接口的微服务都需要进行调整（前后端都可能需要修改）
-
重复劳动（代码文件冗余）：很多为微服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度。那么，导致每个微服务都可能都开发了这一功能，从而导致代码重复。另外，诸如配置，常用的一些工具类，也可能会出现每个微服务中，也导致了代码重复，文件重复。（可将公共部分抽出来作为共享组件，提供给微服务进行引用该组件，但是当开发的语言种类不一样的时候，还是需要进行必要的代码冗余）
微服务架构是一种架构的架构，因为它将市面上一些有些的第三方框架通过无缝的方式（如：maven的pom引入或者使用Gradle引用），进行相应的配置，扩展而构建形成的一个整个服务应用。
市面上的微服务架构主要有：Spring Cloud、Dubbo、Service Mesh。主要介绍Spring Cloud。
下面简单介绍一下微服务架构所涉及到的技术栈。
技术栈有哪些？
