乔212
微服务只是一个概念，是一种架构设计思想，并不是什么新技术。原理就是化整为零，把一个软件应用，拆分为一个个可独立运行的"微"服务，跟常规意义的插件、扩展之类类似，不同之处在于"微服务"是一个可独立运行的应用程序，一般采用容器化部署比如Docker之类。以下从优点、缺点以及适用场景三方面来拆解。
优点，有效解决单体软件随着时间的推移的维护灾难，可按需加载，最大程度释放系统资源。跟开发语言无关，采用容器化独立部署，无论使用什么开发语言都可无缝集成。可以细粒度拆分软件项目，完美的持续集成。
缺点，微服务是一个分布式系统，如果拆分粒度过细，容易形成连环故障。各模块之间需要维护数据的一致性，要规划好通信，对整个系统架构要求比较高。在测试层面来讲，相对单体软件，测试工作量有一定程度的增加。应用部署相对来说比较复杂一点。
适用场景，业务层面，应对多客户需求，通常每个客户总有一部分需求是不一样的。性能层面，应对高并发、高负载。
总之，软件互联网行业知识体系更新比较频繁，新概念、新技术层出不穷，我们探其本质，不要被表象所迷惑。机械科班出身的IT人共勉。
滔朴未来
1. 微服务其实我理解的就是功能专一化，方便升级扩展。微服务有个分而治之的思想。
2. vue和python进行整合，前后端分离可以通过http进行交互分离，vue通过http请求，python提供服务。这就是前后端分离的雏形。
3. 第三代微服务都是通过容器化的方式进行服务编排。互相的调用。
IT人故事会
对于微服务是怎么实现的，我的理解是相对单体应用的交付，微服务应用交付要复杂得多，不仅需要开发框架支持，还需要Iaas、Paas或Caas的支持，以及一些自动化部署的工具。
微服务可以用到：服务注册、发现、负载均衡和健康检查、前端路由(网关)、容错、服务框架的选择，动态配置管理等模块。这些模块可以组成一个简化的微服务 ，利用Spring Boot来实现领域驱动设计概念，并将它们从核心Java转换为预计Spring框架的模型，依靠服务内的Tomcat或者Jetty，被打包为一个Jar文件或者War文件，这个Jar作为单独的进程执行，为所有请求提供服务和响应，并指向此服务中定义的断点的一个微服务。
在前端，一般情况下基本不会用到微服务，所以对于前端来说没有什么关系，主要还是后端的事。目前主流为前后端奋力，这样一套后端服务就可以支持多个项目。这种情况下，前端项目一般是独立部署的，通过接口调用后端服务即可，后端服务也可以根据自己的情况进行微服务拆分。
