讯阳文艺网网友提问：
微服务怎么实现？是前端还是后端的事？
优质回答：
微服务只是一个概念，是一种架构设计思想，并不是什么新技术。原理就是化整为零，把一个软件应用，拆分为一个个可独立运行的”微”服务，跟常规意义的插件、扩展之类类似，不同之处在于”微服务”是一个可独立运行的应用程序，一般采用容器化部署比如Docker之类。以下从优点、缺点以及适用场景三方面来拆解。
优点，有效解决单体软件随着时间的推移的维护灾难，可按需加载，最大程度释放系统资源。跟开发语言无关，采用容器化独立部署，无论使用什么开发语言都可无缝集成。可以细粒度拆分软件项目，完美的持续集成。
缺点，微服务是一个分布式系统，如果拆分粒度过细，容易形成连环故障。各模块之间需要维护数据的一致性，要规划好通信，对整个系统架构要求比较高。在测试层面来讲，相对单体软件，测试工作量有一定程度的增加。应用部署相对来说比较复杂一点。
适用场景，业务层面，应对多客户需求，通常每个客户总有一部分需求是不一样的。性能层面，应对高并发、高负载。
总之，软件互联网行业知识体系更新比较频繁，新概念、新技术层出不穷，我们探其本质，不要被表象所迷惑。机械科班出身的IT人共勉。
其他网友回答
对于微服务是怎么实现的，我的理解是相对单体应用的交付，微服务应用交付要复杂得多，不仅需要开发框架支持，还需要Iaas、Paas或Caas的支持，以及一些自动化部署的工具。
微服务可以用到：服务注册、发现、负载均衡和健康检查、前端路由(网关)、容错、服务框架的选择，动态配置管理等模块。这些模块可以组成一个简化的微服务 ，利用Spring Boot来实现领域驱动设计概念，并将它们从核心Java转换为预计Spring框架的模型，依靠服务内的Tomcat或者Jetty，被打包为一个Jar文件或者War文件，这个Jar作为单独的进程执行，为所有请求提供服务和响应，并指向此服务中定义的断点的一个微服务。
在前端，一般情况下基本不会用到微服务，所以对于前端来说没有什么关系，主要还是后端的事。目前主流为前后端奋力，这样一套后端服务就可以支持多个项目。这种情况下，前端项目一般是独立部署的，通过接口调用后端服务即可，后端服务也可以根据自己的情况进行微服务拆分。
数通畅联专注于企业IT架构、SOA综合集成、数据治理分析领域，感谢您的阅读与关注。
其他网友回答
题主好，很高兴能回答题主的问题。
说到微服务，现在可算是火的一塌糊涂，不管是大厂还是小厂，互联网公司还是传统软件行业，很多都在追逐为服务的热潮。不过，我认为微服务只是新瓶装老酒，其本质就是模块化，这点在问题描述中已经提到了。
那么接下来我们就来分析一下微服务到底是前端的事还是后台的事儿，微服务的具体实现是什么样子的？
模块化
前面我们提到了，微服务只是模块化的延伸。我们在传统的软件开发当中，如果涉及到模块化的话，通常是前端做前端的模块，后台做后台的模块。而在微服务的思想中，强调的是高内聚低耦合的设计思想，尽可能的使微服务可以达到独立开发、部署、运行、运维的目标。
由此可见，如果想实现真正的微服务的话，前端后台缺一不可。否则难以满足高内聚低耦合的设计目标。
实现
微服务其实是一种架构设计的思想，并不强调微服务的具体实现方式。只是微服务作为一种天然的分布式架构，又有如此高的设计要求，实现的复杂性自不必说。好在无论Java、Python还是其他的编程语言，都有好心人和大牛提供了相应的实现框架。
因此，题主完全可以不用担心，Python和vue是可以搞出微服务的。
建议
前文提到微服务是一种设计思想，在各种社区，也能找到各种编程语言对应的微服务实现框架，但是我非常不建议题主在做全栈项目时使用微服务这种设计思想，但是对于框架的学习，建议题主还是要尽可能的掌握。甚至未来参加工作了，依然是这个建议。也就是说不到万不得已的时候，不要触碰微服务！
其他网友回答
微服务的概念近几年很火，很多大厂也在力推微服务，但也不用把它神话，实际上绝大多数场景根本不需要上微服务。
微服务的目的就是为了系统解耦、把可以服用的组件拆分为可以独立工作的模块，从这个层面来看，微服务既可以是前端模块、也可以是后端模块，而且微服务往往和容器虚拟化技术结合来使用，k8s+docker已经成为了微服务的最佳实践，基本上可以认为是微服务的事实标准方案。
举个电商秒杀活动的例子，对于前后端分离的架构，我们可以把前端秒杀页面放入docker容器（docker中要部署web服务器），把后端的秒杀商品查询、下单、付款分别放入不同的docker容器（可以是springboot的应用），然后通过k8s对这些容器进行管理、实现服务发现、流量负载、弹性伸缩等，当然，对于数据库建议不要放到docker容器中、还是老老实实的放在物理机或虚拟机环境下。
虽然微服务有一大堆好处，但麻烦事也不少，对运维人员的要求更高，问题定位、处理故障更不容易，如果开发人员不多、平台的流量相对稳定，建议还是尽可能用传统架构，“LVS+nginx+应用节点+缓存+读写分离”的方式可以满足绝大多数系统的访问要求了，别必要给自己挖坑。
欢迎探讨。
其他网友回答
你好，很高兴回答你的问题！！从以下几个方面阐述：
软件行业的分类
以上提到了两种架构方式：
1.单体式架构
通俗的讲就是所有的源代码在一个项目中，并且把这一个项目部署到服务器，当某个模块的访问流量增加，一台服务器难以支撑时，会把整个项目复制到新增的服务器上。以此类推..
这种架构有一个很大的缺点，就是并发配置不灵活，无法针对某个并发量大的模块进行并发配置，而是整个项目复制部署，这样会导致服务器资源的极大浪费。
所以就有了下面的架构方式：
2.分布式微服务架构
将项目拆分几个独立的功能单元（服务）的架构，每个功能单元就是一个服务。
这个服务的细粒度，根据实际情况可以很细，也可以很粗。
一个大型系统的甚至可以有成百上千个服务，这些服务之间彼此独立又互相联系。
优点：
1.降低了项目的复杂度
2.团队的职责界限明确
3.部署灵活
服务类型
在系统中所有的服务，可以分为以下两种类型：
服务提供者 （Provider）
即提供服务的一方
服务消费者 （Consumer）
调用服务的一方
即把每一个拆分出来的模块，继续拆分成消费者和提供者！！
拆分之后消费者如何调用？如上图消费者和提供者之间多了一层-注册中心
注册中心 （Registry）
注册中心类似于生活中的婚姻介绍所，男女双方都把各自的信息提供给婚姻介绍所，由婚姻介绍所，权衡双方信息，为男生女生选择“门当户对”的另一半
说的书面化一点：负责服务的注册与调用服务的注册中心，常用的注册中心有Zookeeper等
以上提到的注册中心（Registry）、 提供者（Provider）、消费者（Customer）是微服务框架Dobbox分布式微服务框架的三种主要角色
Dubbox框架
Dubbox是一个分布式微服务框架，前身是阿里巴巴的开源项目Dubbo，后来阿里不再维护此框架；进而当当网进行了进一步维护，为了和Dubbo区分就取名为Dubbox
Dubbox运行原理图解：
调用关系说明：
1. 服务容器负责启动、加载，运行服务提供者
2. 服务提供者在启动时，向注册中心注册自己提供的服务
3. 服务消费者在启动时，向注册中心订阅自己所需的服务
4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台
6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
如何实现微服务
1.安装Zookeeper
下载链接：
https://zookeeper.apache.org/releases.html
1.1解压安装包
1.2重命名 /conf/zoo_sample.cfg
1.3在Zookeeper主目录下创建data文件夹
1.4修改配置文件
zoo.cfg
指定dataDir为刚才创建的目录
记住访问端口2181
1.5双击启动服务器端和客户端
zkServer.cmd
服务器端
zkCli.cmd
客户端
启动后不要关闭，至此注册中心搭建完成！！
2.搭建管理控制台dubbo-admin
1.1从GitHub获取dubbo-admin
1.2切换到分支2.5.8
1.3使用Maven编译打成war包
进入到dubbo-admin目录
编译打包 ： mvn clean package -DskipTests
1.4将war包部署到tomcat服务器并启动tomcat
这里不再赘述
1.5修改dubbo.properties文件
这三项目前不用修改
#zookeeper地址
dubbo.registry.address=zookeeper://127.0.0.1:2181
#root用户密码是root-登录dubbo后台使用
dubbo.admin.root.password=root
#guest用户密码root-登录dubbo后台使用
dubbo.admin.guest.password=guest
以上两个用户名密码很多人容易出错！！
我们输入以下地址访问：
http://localhost:8080/dubbo-admin-2.5.8/
用户名：root 密码：root
看到这个界面说明我们的管理控制台搭建成功
3.编写Consumer和Provider
项目结构图：
3.1创建公共模块(shop-common)
提供了公用的api及model等
实体类User
接口UserService
2.创建Provider
引入依赖
配置dubbo
服务实现类
@Service: dubbo提供者服务用于声明对外暴露服务，只能定义在一个类上，表示一个服务的具体实现
interfaceClass：指定服务提供方实现的 interface 的类
启动类
@EnableDubboConfiguration 将会自动扫描dubbo的service服务
3.创建Consumer
引入依赖
配置dubbo
创建UserController
@Reference 用于dubbo消费者服务指明引用哪个提供者接口服务
url：通过指定服务提供方的 URL 地址直接绕过注册中心发起调用
4.访问Controller
输出“hell dubbo!!”，说明微服务项目搭建成功
基于理论开始，到创建一个案例，到运行测试整个过程都详细描述，看完应该知道微服务怎么实现了，看过之后相信也知道微服务到底是前端还是后端了。
如果有需要源码或安装包可以私信我！！
