前言
目前越来越多的话题都围绕着微服务，许多公司也在使用微服务架构。笔者也刚刚接触微服务不久，也算是微服务架构的初学者，谨以本文来记录学习过程中对微服务架构的一些理解。好啦，废话不多说，我们往下看。
1.微服务是什么？
微服务，英文名MicroService，他是一种架构风格一种架构设计模式，通常表现为一个庞大而复杂的应用其背后是由数个职责分明的服务组成，这些服务他们各自分工明确，可以独立部署同时也可以根据需求进行扩展，各个服务之间松耦合并且可相互通信。
结合我们生活来说，一个公司内部组织架构也算是一种微服务的表现，公司内部按不同职能划分了许多部门，人事部门、财务部门、开发部门、测试部门、运维部门等等这些部门都是一个个的微服务，各个部门之间相互独立办公同时也相互协同办公。这些所有的部门组成了公司的整体。
微服务的概念出自于马丁·福勒（Martin fowler），他对微服务的定义如下：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于 HTTP 协议的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，对具体的服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建 。（摘自王磊先生的《微服务架构与实践》）
2.为什么要用微服务？
微服务从最初的无人问津，到现在大红大紫，被大家广泛使用。那么问题来了，为什么要用微服务架构？为什么就不用以前的架构了？我们先来了解一下传统的架构方式。
2.1单体架构
应用程序作为单体进行打包和部署，称之为单体应用，例如基于SpringMVC+Mybatis+Spring开发的许多Java项目最终被打包成一个war格式的文件部署在Tomcat或者Jetty服务器上。而这种单体应用的架构理论就称之为单体架构。
2.1.1单体应用的局限性
一个单体应用他可能内部也区分了业务逻辑模块，但最终都打包为一个单体，随着时间的推移，单体式应用的不足就暴露出来了。
- 复杂度高难以理解
- 随着时间推移，业务需求的升级，代码量越来越大，项目内部逻辑变得越来越复杂，各个模块之间区别模糊，逻辑混乱，开发人员对于代码的理解难度加大。
- 代码维护难度升级
- 时间线拉长后，一个项目可能会有许多程序员接手，代码复杂度增大之后，前人留下的坑后人来填，刚上手的程序员可能会面对一个又一个问题。
- 部署速度之间变慢
- 单体架构的应用内部业务模块众多，每次功能的变更都需要重新部署整个应用，项目的启动时间可能从最初的一分钟演变为最终的十分钟，这种情况乱其实很多
- 可靠性稳定性直线下降
- 由于整个项目是部署在一个实例中，一个小小的bug可能就会导致整个应用的崩溃。
- 技术创新难以实现
- 受项目本身限制，团队成员必须使用一种框架和语言，模块无法明确清晰的拆分，升级框架和使用新技术的风险和成本很高。
- 资源需求冲突难以解决
- 不同的业务对物理资源的需求是不同，比如处理图片音乐视频的模块是CPU密集型的模块，而像订单、日志等是属于IO密集型模块，当需要提升IO密集模块性能时，但由于我们的应用是单体架构，所有模块都在一个架构下，所以我们想要对某一模块进行升级扩展不得不考虑其他模块。随着需求进一步变更，资源需求冲突会成为整个应用最大的痛点。
单体应用在面对这写日益严峻的问题时，微服务架构则从根本上杜绝了这些隐患的产生。
3.微服务能用在哪？
微服务架构往往用于解决复杂问题，他适合将复杂庞大的问题拆分为相互独立又相互联系的小个体。相比于单体架构，微服务架构是构建业务复杂度高，规模大，需要长期持续迭代这一类应用时更好的选择。
现在已经有很多公司采用微服务架构来解决单体式架构可能会造成的隐患，笔者所在的团队就选用了基于SpringBoot的SpringCloud，如此一来能够大大提高开发效率的同时降低项目的维护难度，将项目分解为多个微服务组件，各个相对独立的同时又相互协作。不用再构建并且维护一个臃肿又令人头疼的单体应用。
3.1主流的微服务框架介绍
- Spring Boot
- Spring Cloud
- Dubbo
- Dropwizard
- Akka
- Vert.x、Lagom、ReactiveX、Spring 5
4.微服务的优点
说了那么多，那在使用微服务之后到底有哪些优势呢？
1.应用复杂度降低，代码可读性高，易于开发。
- 服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护。
2.容错率更高
- 由于各服务相互独立，当某一模块出现bug，只是针对与某一个服务组件出现故障而已，不会影响其他模块的使用，同时开发人员可以快速的解决问题。
3.技术选型不受影响
- 各个服务独立，完全可以使用不同的语言来实现其内部业务。
4.资源冲突问题顺利解决
- 在单体应用中存在的资源冲突问题，在微服务中，我们完全可以根据服务本身的特性对性能进行升级。
5.微服务的缺点
任何架构都是在实际开发中慢慢演化出来的，是为更好地适应开发者们的需求。所以微服务也存在着自身的不足之处。
1.对开发者要求更高
- 各个服务根据不同业务，使用到的语言、数据库、技术都存在差异，这对开发者本身就是一个挑战。
2.运维难度提升
- 微服务架构有许多服务组件，而部署一个微服务应用也是十分复杂的过程，单体架构中只需要维护一个应用的正常运行，但是在微服务中，但是一种服务可就就有很多实例，可能需要维护数十个服务，所以自动化部署也是应用成功运行的基础。
3.微服务自身的复杂性
- 为服务应用本身就是一个分布式系统，从整体上来说它也十分复杂。
6.总结
没有哪一个好的架构是被设计出来的，也没有哪一个架构可以解决所有的问题，每一个好的架构都是在不断适应业务需求的过程中不断被演化出来的。所以每种架构方式都有各自的优势和缺陷，没有最好，只有最合适！
