微服务是什么？
微服务简单来说的话，其实就是将一个大型的系统拆分成各个小型的服务，他们之间拆分的颗粒度可以是以一个模块、一个功能菜单甚至是一个方法做为单独服务，但是需要注意，“微服务”与“微服务架构”有着本质的区别： “微服务”强调的是服务的大小，它关注的是某一个点。而“微服务架构”则是一种架构思想，需要从整体上对软件系统进行通盘的考虑。
微服务架构又是什么？
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、拟生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
微服务架构的特性
微服务架构应该具有一下特性：
4.进程隔离；
单一职责
通俗来讲就是专业的人做专业的事，在微服务架构中的每个服务作为一个单元，它们都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则，不同服务之间通过“管道”进行相互通信，从而构建成一个庞大的系统。
轻量级通信
所谓的轻量级通信指的是与语言无关、平台无关的交互方式。
对于轻量级通信的格式而言，我们熟悉的 XML 和 JSON，它们是语言无关、平台无关的；
对于通信的协议而言，通常基于 HTTP，能让服务间的通信变得标准化、无状态化。目前大家熟悉的 REST是实现服务间互相协作的轻量级通信机制之一。使用轻量级通信机制，可以让团队选择更适合的语言、工具或者平台来开发服务本身。
独立性
所谓独立性，是指每一个服务从开发、测试、部署都是单独的。
在单体架构中所有代码都是在相同的代码库中，每个功能都不具备独立性，当不同小组完成开发之后还要进行集成和回归测试，测试过程也不具备独立性，当服务测试完成进行部署时，如果出现bug或者某个模块出现问题，将导致整个应用进行回滚，部署过程也不具备独立性。
进程隔离
在单体架构中，整个系统运行在一个进程中，当应用进行部署时，必须停掉正在运行的应用，部署完成后在重启，无法实现独立部署。
在微服务架构中，应用程序由多个服务组成，每个服务都是独立的个体，它们部署在各自的服务器上，并且运行在独立的进程中，当需要进行应用部署时，只需要停掉对应的服务即可，与之不相关的服务依然能继续使用，实现了进程隔离、独立部署。
架构演进-单体架构
传统服务一般采用单体架构进行开发，其优点是部署简单、技术单一、用人成本低，缺点是系统启动慢系统错误隔离性差、耦合性强、可伸缩性差、线上问题修复周期长。
架构演进-分布式架构
将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。区别分布式的方式是根据不同机器不同业务。
优点：
1、减少了单个应用对服务器的压力
2、模块重用度高
3、部署效率更快
4、系统扩展性更高
5、易于团队协作
缺点：
1、架构设计变得复杂
2、部署繁杂
3、服务响应时间变长
4、运维工作繁琐
5、技术多样化、运维多样化
6、架构复杂需要更多的技术支撑
7、数据一致性问题
架构演进-微服务架构
微服务的设计是为了不因为某个模块出现问题而导致整个系统不可用情况出现。微服务的部署方式跟分布式的部署方式有略微差异，微服务的应用不一定要部署在不同的服务器上，它也可以部署在同一台服务器上。
如何进行服务升级
在进行服务升级之前，应考虑以下几个问题：
确定完以上几个问题之后，便可以着手进行服务升级；
以上：是我基于微服务的思考，欢迎大家补充指正，谢谢。
