听着陈奕迅的《K歌之王》，开始了这篇博文的书写。首先为什么是纸上谈兵呢，因为我并没有在实战场景下自己搭建过整套微服务，不过在美团内部确实是一直在用微服务，所以这篇博文更多是我看书和在美团看到的东西后的一些思考，当然这些思考是来自于一个专门做java后端刚满一年的人。
背景
在准备专门做Java后端前，想着可以真正深入学习或者做一些东西，例如一些中间件。开始做之后才发现，似乎只需要安安心心的做业务就行了，其他的该有的都有了。美团的中间件非常完善，只要我想到的，基本上都有，慢慢的也就习惯用这些中间件进行开发了。但是当我要离开美团的时候，就很纠结了，离开了这些中间件，我还怎么开发？虽然我一直在用微服务，但是我从3个月前，才真正的开始了解它。因为才做后端一年，找工作确实有点难，所以后面就要把时间放在其他的东西上的，所以只能先把这些东西写下来，也证明这几月没白折腾。
后端的变化
通过这张图，可以看出后端在这十几年的变化，从单体应用到分布式再到微服务，后端服务架构的变化并不是某个大牛说应该这样就变成这样的。而是因为随着业务的发展，对于后端的要求也在进行变化。在网站创建初期，用户量并不多，所以一个单体应用配合一台比较好的机器就可以支撑业务；后面用户量和访问量的增加，这时候单台机器已经搞不定了，所以有了负载均衡，有了分布式；随着移动互联网的发展，访问量急剧增加，用户对于服务的稳定性也越来越高，这时候就演变成了微服务的架构。为什么微服务的稳定性会更高，因为通过将原来的单个应用根据功能分成各个服务后，就可以很容易实现降级、独立部署等功能。特别是降级，我还记得很清楚的一次是春晚支付宝刷红包，差点把支付宝搞崩了，后来听说他们已经准备的机器数比双11的几倍，但是还是撑不住，只能通过降级先顶住。
该不该用微服务的架构
微服务能增加业务的可用性，为啥还问该不该？首先我要先说下美团的情况，在美团内部，有专门的一个团队在维护公司的的微服务系统，每一个中间件也有专门的团队在进行维护，而这个维护成本对于小公司能不能承担？能不能招到能维护的人？当然有些人说开源框架那么多，拿过来自己部署一套不就好了，这个当然没有那么简单，我开始了解微服务的时候，是通过spring-cloud入手的，当然现在也仅限于它，当我第一次听到的时候，我也以为只是一个开源库，拿过来就可以用了，真正了解后，才发现这是套框架，里面包含了太多的各种组件，所以spring-cloud也是通过名字来作为版本号，因为不同的版本号里面对应的各种组件也有自己的版本号。部署完后还不一定能直接用，还需要定制一些东西，规定一些开发规范和流程。
公司的业务需不需要它，搭建一套微服务是需要成本的，所以取决于性价比。在我看来，如果业务相对简单独立，就没必要了，因为也分不出什么服务出来，反而可能会影响业务的稳定性。如果业务正在快速增加中，就可以开始考虑部署，但是我还是建议步子不要跨太大，容易扯到蛋，应该从边缘业务开始尝试接入，然后慢慢进行转移，还需要进行各种压力测试，需要先保证中间件服务的稳定性，才能保证业务服务的稳定性。
在我来看，如果一次版本迭代的周期因为开发功能太多，模块太多导致时间过长，就可以开始考虑，或者十几个人开发在同一个应用里进行开发，并且开发不同的功能，也可以开始考虑。
微服务有哪些东西
正常这个部分应该开始介绍什么是微服务的，给个定义原则啥的。不过我看过的书也很少能给准确的定义，所以我只就写写我不够准确的理解。一款产品都有各种各样的模块，例如一款电商产品，有商品模块，订单模块，用户模块，支付模块。而在微服务里，这些模块在后端都是单独作为一个应用存在的，而这些应用都提供某种服务，所以整套架构就成为微服务。说白了，就是代码解耦，面向接口编程。
上图是我认为微服务应该最基本拥有的，当然还有很多东西没有包含在里面，后面我会单独介绍一些模块，然后尽量解释清楚，然后把一些没有标识出来的东西也尽量写出来。
服务名
微服务架构的服务数量几十个算少的，几百个算正常。为了便于管理，我们需要有服务名的命名规范，来保证服务名不重复，也便于通过服务名知道，这是哪个产品的哪个服务，例如用类似maven的groupId+artifactId做为服务名
Nginx和网关
对Nginx和网关有了解的人，可能会认为他们的功能是重复的。首先在我整个架构中，Nginx是管理对外服务的，而网关服务是管理内部的。也就是所有外部来的请求都会先经过Nginx，到达网关后，网关根据配置信息转发到具体的服务中。因为所有的流量都会经过网关，所有网关一般会有多台机器，然后通过nginx进行负载均衡，分发到各个机器上。如下图:
服务管理中心
服务管理中心，一般也成为服务治理中心。当我们将各个应用拆分成各个服务后，就会导致服务量的数量很大，所以我们需要一个服务治理中心将这些服务管理起来。当我们新增一个服务的时候，都会给他分配一个服务名，然后在服务代码中配置该服务名，当服务启动的时候，需要先通过这个服务名来服务治理中心进行注册。当我们把服务治理中心和网关配合起来的时候，就可以实现机器的上线和下线功能，网关从服务管理中拉取服务的可用实例列表，然后将请求发送给他们，当在服务治理中心，将某台机器配置为下线，那么网关就不会把请求发送给他了。
服务间通信
在微服务架构中，有很多服务，服务和服务之间需要进行通信，在我看过的微服务的书中都是通过http进行通信的，这样的做法有一个好处就是服务之间耦合性会没有那么强，而且通过接口文档，也可以让一个新服务很快进行接入，当然也可以将这些接口封装为一个sdk，提供出去。不过我也见过很多使用tcp作为通信方式，这样会比http的性能会好很多。
日志中心
日志中心通过名字就能明白他是用来管理日志的，在日常开发和维护中，查看日志都是很重要的手段，而现在一个服务基本都是有几台机器，当出现问题了，如果不知道是哪台机器，可能就只能一台一台的找过去了，所以这时候日志中心就很重要了，将所有机器的日志都上报到这里，我们可以通过日志中心直接查看所有机器的日志，也便于调查问题了和统计数据。而当日志中心和服务管理中心配合起来，日志中心就成为所有的服务的中心，可以直接通过服务名进行管理。
配置中心
随着服务越来越多，我们需要可能对同一个服务的多台机器进行统一配置，也需要将一些通用配置对多个服务进行统一配置，所以配置中心是必不可少的。
数据库管理服务
在微服务结构中，一般都是单服务单库，也就是一个服务对应一个库。这样能降低随着业务增长对于数据库的压力，当然这样也增加了对于数据库管理的压力，几百个服务，可能会有几百个库，所以在我看来需要一套比较完善的数据库管理服务，不过这个点在我看过的书中很少提到。书中提到一般都是如何实现主从分离、分库分表等功能，这些当然很重要，但是不应该让服务方实现这样的功能，而是应该配合管理服务提供相应的接入中间件，在中间件中实现这些功能，然后让服务方进行接入就行了，然后在管理服务中进行配置。
缓存管理服务
几百个服务中有些需要缓存有些不需要缓存，怎么让他们方便的接入是个问题？几百个服务共用一个缓存服务，命名上的冲突需要解决？所以缓存管理服务就是专门用来管理各个服务的缓存使用，定义命名规范，也可以做相应的中间件，实现一些动能。
跟踪监控服务
在微服务架构中，用户的一次调用，可能涉及到很多个服务，如果有某一个服务除了问题，怎么调查？怎么确定是哪个服务，哪台机器？所以跟踪监控服务就很重要，他需要可以实时跟进当前所有的服务的运行情况，调用链情况，当出现问题后可以实时发现，并发送报警通知。
其他中间件服务
在微服务架构中，服务一般是分为两种，一种是业务服务，一种是中间件服务。中间件服务是为业务服务保驾护航的，所以一般当有一些新的技术需求，一般都是新建一个服务专门做这个。例如某个业务需要接入hbase，但是公司内部还没有该服务，但是评估发现确实是需要这样的服务，就可以新建一个服务，专门提供hbase的各项功能，然后让业务服务进行接入，当有其他业务方也要接入时就很方便了。
结尾
我在了解微服务的时候，脑子里有无数个想法。但当我开始写这篇博文的时候，有些想法却很难表达出来，这可能就是词不达意吧。这可能跟我的写作能力相关，而且因为分两天写完，第二天写的时候思路全断了，一些细节就也没有继续解释清楚，挺遗憾，希望后面还有机会可以来完善这篇博文。
