微服务一：概述

微服务是最近几年大热的话题。不过这倒不是这几年才有东西，而是在零几年就有大公司们实施了，不过那时候不叫这个名字。

一、微服务是什么

所谓微服务，就是大的服务器拆分成各种小的服务器，由各种不同功能的小服务组合成对外完整功能的服务器。

为什么需要拆分呢？

传统型单服务的问题

以前，一个产品，一般对应一个后台服务器。随着功能不断迭代，服务器代码越来越复杂，越来越庞大，问题也越来越多：

1. 维护成本高

随着时间推移，不断迭代，产品功能增多，模块不断增加，开发人员增减、变化，都在一起进行，这些都会相应增加维护成本。需求增加，可能会造成模块间的交互错综复杂，接下来开发的时间成本必然增加。如果开发时间不足，会引起代码混乱，得不偿失，但这是很常见的情况，不懂行的上司或老板们会说：“明明上个功能不用这么长的时间呀，得加快”。复杂、功能多的产品，代码量也不少，那新入职的开发者想要上手的时间也就会增加，因为老代码不是想动就能动的（国内测试驱动开发可不多），万一造成线上问题呢？

由于是单系统，当新版本上线时，势必需要重启线上环境。大型系统启动时间是有成本的，也许是几十秒钟，也许是几分钟。也许咱们只是修复部分数据显示错误的问题，但整个系统重启，想想那些正在使用其他功能的用户们，体验肯定不好。

2. 开发成本高

同样地，维护成本增加，开发成本也必然增加。数据库增加表、老表加字段等。我甚至听说过200多个表、单个表超过 50 多个字段的数字库，想必这开发起来还是蛮有难度的。

3. 系统扩展困难

随着系统的用户增加，系统的压力会随之增大，内存需要更大的，CPU 需要更快的才能系统的需求。这时就需要升级硬件来满足扩展的需求，但硬件升级很容易就到头，而且成本也非常高。所以通过硬件升级，上限是很低的。

来看看这个搞笑的极端例子：史上最烂的项目：苦撑 12 年，600 多万行代码。

上面例举了部分单机服务器的问题，咱们再来看看微服务。

微服务方案

微服务就是将单个系统根据功能拆分成多个功能完备的小系统。比如，一个电商产品，可以分解成：用户服务器、订单服务器、商家服务器、产品服务器、秒杀服务器、产品推荐服务器等。

通过拆分后，有不少的优点：

1. 单个小服务器开发成本低

服务经过拆分后，单个服务的功能少，清晰，开发起来当然更简单。新入职的开发也能更简单上手了。

2. 单服务维护成本低

服务小了，维护起来更简单了。由于代码量少、依赖的东西少，启动速度也更快一些。

3. 扩展简单

多个小服务，我们可以布署到多台机器上。甚至可以到达上万台机器。这样系统压力增大时，我们可以通过简单的增加低成本的服务器即可达到扩展的目的。

4. 不限制语言

一般单系统时，我们会采用一种或少数语言开发。现在只有服务器采用统一的通信方式(如 rest api)，就可以不限制语言了。比如有的用 Java，有的用 C++，有的用 Node.js 等，任由工程师们发挥。

二、微服务的问题

微服务解决了不少单系统的问题，但同时，它也有不少自身的问题。

1. 服务器间的交互成本

用户功能是多个微服务间交互完成的。比如用户下单，会涉及到用户服务、订单服务、支付服务、仓库服务等。这些交互都是通过网络异步进行的，速度肯定没有单服务器来的快。

2. 服务管理难

如果有非常多个微服务，那就需要有能管理服务管理工具了。想想，如果有成面上千个服务，纯靠手工一个一个管理，是什么样的场景，运维会哭瞎吧。另外，如果某个服务崩溃了、或者网络线缆被挖断了等问题。

3. 事务成本

以上面例子来说，单系统下，直接开启数据库事务即可。但在多服务下，很难保证所有服务都不出问题。

4. 调试难

由于常有跨服务调用，当出现问题时，我们很难快速定位到问题所在。

当然还有其它问题和挑战，都是多服务才有的问题。

总结

微服务是将单系统拆分成多个服务。一个完成的功能通过多个服务间调用达成目的。其解决了一部分单系统下的问题，但它有多个自身独特的问题，它并不是万能药。如果系统的功能不多，或者只能少数开发者，则不建议采用微服务，或只拆分出少数服务。