关于微服务的文章，网络上很多，也比较专业。下面，我尝试着用简单的话写点自己对微服务的理解，非常接地气，但只是一家之言，大家还是带着辩证的眼光来读。

1、微服务的本质是什么？

微服务的本质是：分而治之。其实这四个字可能用在很多地方，比如模块的划分、类的划分、方法的划分。在微服务这边就是进程的划分，即将不同的业务拆成独立的进程。

2、微服务会降低项目的复杂度？

会。我所说的”会“是指会降低业务上的复杂度，而不会降低技术上的复杂度，其实，技术上的复杂度会大大增加。原来我们所有的业务都放在一个项目，即一个进程中，业务纵横交错，人员变更快，会很快让一个项目的代码变得难以维护，比如冗长的类和方法、随便放的文件夹等等，想想你有多少次想重构代码的冲动就知道了。业务上如果拆成独立的服务后，业务关联少，代码就会简单很多，一个服务只处理自己或与之关联很低的业务。

3、微服务怎么进行业务拆分？

想要拆分好微服务，首先得对自己所在的项目业务有充分的理解。我们做技术的，非常喜欢追求高大上的技术，而瞧不上公司的增删改查，觉得写curd，显得自己很low。其实，我们可以想一想，你匆匆忙忙写完curd后，然后去看高大上的技术文章，自己是真提高了还是只是幻觉？你看的那些，你能落地到你的项目中，帮公司解决实际的业务问题么？有时候，我们是搞反了。

4、微服务的涉及到的技术栈有哪些？

太多了。以前我们单体应用，建立个三层就可以了，比如一个BS项目，.net使用AspNetMvc即可，java使用ssm或springboot就行。把业务拆成独立服务后，涉及的技术栈就太多了，比如通信相关的thirft、grpc、http，服务治理相关的consul、eureka等。这些就不一一列举了，网上文章太多了，这些没有好的建议，都是和工具相关的，总之多实践就行，而不是看文章。

5、微服务怎么部署？

单体服务的时候我们可以使用IIS或tomcat部署，现在拆成多个服务后，比如订单服务、商品服务、短信服务等，有的服务需要集群，而有的服务只要单个，需要用到服务注册发现，本质上其实就要能得到服务的IP和端口就行。微服务后，大家应该都知道的，单机使用docker、docker-compose，集群使用k8s。

6、微服务通信使用http还是grpc？

建议公网使用http，内网使用grpc。

7、微服务是否需要网关？

需要。业务拆成多个微服务后，比如多个http服务，我们不能将服务直接对外暴露给客户端，需要添加一个网关层，做数据的聚合，比如订单列表接口，需要调用订单服务和商品服务，才能组装成客户端需要的数据。网关其实就是webapi，不同的业务有不同的webapi，比如管理后台调用管理后台的webapi，移动端调用移动端的webapi。但一些公共的操作，比如登录、认证、限流等功能，需要每个webapi都要实现一套，为了将这些操作统一，可以在这些webapi上加一层公共的网关，由网关统一实现上面列举的功能，并根据规则将客户端请求路由到对应的webapi，比较出名的有ocelot。

8、老项目需要重构成微服务么？

不推荐。老项目通常比较稳定，当然，代码也比较混乱，重构的风险太大。新项目在充分调研后，可以使用微服务。不过提醒一下，微服务涉及的知识非常多，使用需谨慎。

9、总结

微服务最重要的理念就是将复杂庞大的业务拆成一个个简单清爽的独立服务，所以一定要先理解自己公司的业务，不能照猫画虎，记住四个字：分而治之。微服务涉及到的框架工具，建议少看文章，动手操作一遍，也是四个字：知行合一。

如果本文对你有所帮助，就给个“赞”吧！