微服务的好处与弊端_要上微服务，先考虑好这几点再说

今天一个朋友问我，我想做一个项目，两年内做到1000w用户量，并发数1000左右，需要用微服务吗？

最近不知道什么时候，微服务一下火了起来，人人在说微服务，很多公司都在用微服务，

今天就来讨论一下，是所有项目都适合微服务吗

1.什么是微服务

微服务应该是从java那边传过来的，java的spring boot、dubbo，然后golang的go-micro,

就连php也有了微服务，phper肯定不满啦，PHP咋了，作为世界上最好的语言，怎么就不能有微服务！

哈哈，其实我也是一个phper。

一般情况下，我们项目初期都是单体架构，好处是简单，易开发、易维护、易排查，还有易交接，

可是随着功能越来越多，越来越复杂，例如一个系统有用户模块，商户模块，订单模块，认证模块等，系统需要提供

web api，移动 api，后台api等

mvc

这时候，把系统功能按模块拆分开，把原来大而全的单体应用拆分成功能独立的、自洽的小而美的多个应用的组合。这就是微服务

每个服务负责自己模块的功能，独立开发、运维、部署、维护，互不干扰，用什么语言，采用什么架构自己说了算，相互之间可以通过协议通信

micro

2.微服务的利弊

先说好处：

a. 服务分治，相互独立，可独立技术栈，DB设计，更高的自主性；

b. 每个服务做到高耦合，外部接口交互数据，可扩展性强；

c. 有利于对抗高并发，性能较好；

不要以为用了微服务就万事大吉了，能把微服务安全落地，稳定跑起来可不是容易的事情，凡事有利就有弊，说下弊端：

a. 开发、测试、运维难度增加，本来一次搞定的，却要分开多个，每个都要来一遍，谁能不崩溃！

b. 稳定性差，调用链复杂，一个崩溃，一个性能差，可能影响多个业务；保证自己没问题，但保证不了别人的服务没问题呀！

c. 出现错误排查难度增加，定位不准，不同的团队之间，就会相互推诿！

这时就需要一个监控系统，监控系统每个组件的运行情况啦！

总之，搭建微服务，需要强大的配套系统才能稳定的跑起来。

业界对微服务的应用也是褒贬不一，用好了是一大利器，用不好就是找死，目前没有点实力的公司还是很难玩的溜。所以用不用要谨慎，想用前考虑好服务粒度细、体系架构复杂、开发效率低、服务治理难，监控维护难这些问题，用微服务，道路是曲折的，前途也不一定是光明的，也许就是一条不归路。

3. 需要考虑哪些？

a. 服务拆分，拆分是一个很麻烦 的活，系统内部可能有千丝万缕的联系，相互调用，如常见的连表，拆不好内部就是一团乱麻，难以维护，充分考虑自己的需求，合理拆分！分布式的数据强一致性，也是业界 的难题

b. 选好语言，找一个跟自己需求匹配度高的框架，这样可以省很多事。目前微服务这块java可能是首选。

网上很多文章把微服务说的很高大上，但是能用好可不是容易的事情。

因为微服务架构本身的复杂性，初创公司系统出于快速开发、快速验证的考虑，很少在一开始就使用微服务架构，后面看情况要不要用微服务。要用微服务，首选把分布式系统稳定跑起来再说吧。毕竟不是所有系统都适合，何必拿大炮打蚊子呢。

微服务都是逐步演进的，不是一蹴而就的，演化思路应该是一步步铺基础设施，一点点拆分微服务。

微服务是一个很大的话题，里面的内容可以写一本书了，所以很难把细节将清楚。本篇文章就当做是概念介绍吧！