前言：微服务是最近几年流行的一种架构思想，首先我们可以看下某官方发言人对于微服务的解释：微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。
说了这么多，感觉像是没听懂呢，不用着急，那我就把微服务做下总结吧！
1.独立部署，灵活扩展 传统的单体架构是整个系统为单位进行部署，而微服务则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。这里我打个比方，就拿淘宝来说，该网站是在某一时刻访问量会暴增的电商网站，其中有个人用户中心，个体商户，商品订单等等方面，一般在双11时期，它的订单方面的并发量肯定特别的高，所以就需要加强这个模块的高并发处理量，这样我们就可以使用微服务来实现订单模块的加强。而这几年流行的Docker，又为微服务架构提供了有效的容器（都不晓得，这个容器技术感觉有点像当年的python，因为人工智能一下子火起来了）。
2. 资源的有效隔离 微服务的设计的原则之一，就是每个微服务拥有独立的数据源，如果A想读写B的数据，就只能调用B对外的接口来完成，这样也可以避免多服务之前争用数据库的问题，同时，这里就涉及到了各个微服务之前的通信问题。由于每一个微服务都是在容器上运行，包括项目的配置环境和使用数据库的版本都可以独立开来。
3.团队的组织架构调整 之前的团队都是前端有前端的小组，后端有后端小组，测试有测试小组。而微服务的设计思想是对团队划分有了一个新的架构，让前端和后端及测试、DBA成为一个整体的小组，单独负责一个订单模块，这样垂直划分有利于各模块的独立开发。
说了微服务这么的优点，我个人感觉微服务也有一下几个缺点：
- 当然是各个服务之前的分布式通信问题，各个服务要实现互相的通信；
- 我觉得是对于数据的操作，可能A服务需要操作B服务的数据，这个时候如何做到协同一致，避免数据出现错误；
- 不同微服务实例的管理，可能服务A是用python来做的，服务B确是用java来做的，这就要求配置不同的开发环境和生产环境，同时对后端开发人员的技能要求也会高些。
PS：这些只是目前我对于微服务的一些简单理解，如有不足之处，还请大家提出改正，谢谢！
