我们曾经的服务-单体服务
我们对于一个新模块开发时，好多小伙伴就会问为什么我们要搞微服务架构，一个项目把代码从头撸到尾不是很方便吗，开发更快速，部署也容易。如果使用微服务，涉及的技术就一大堆，中间还容易出现各种不一致的问题。对于这种问题怎么回答呢？那我们就先看看我们以前做个B-S服务是啥样的吧。。。
最开始我们都是弄一个tomcat（服务容器）+mysql（数据库）直接就把项目打成war包扔到tomcat下直接启动部署，通过浏览器就可以访问了。有的甚至是服务+页面+数据库都在一台机器上直接就上到网上了给用户提供服务了。那个时候我们主要主流技术（B-S）架构大概是这样的：
- 阶段一：jsp（页面）+java+struts1+hibernate+spring+mysql
- 阶段二：jsp（页面）+java+struts2+hibernate+spring+mysql
- 阶段二：jsp（页面）+java+springMVC+mysql
可能随着用户的增加慢慢的出现服务瓶颈，比如服务卡顿，页面返回慢。就出现了多服务部署，用nginx做个反向代理，像下面的情况：
之后又发现数据出现瓶颈，做成主从架构来增加读的服务器，主数据库保证数据的一致性，使用从服务分担查询请求，主服务器会把数据同步到从服务器中实现数据的最终一致性。当然这个架构可以还是会遇到性能瓶颈，不过可以暂时用上很长一段时间了。
慢慢的配上缓存，如果配上缓存，静态文件分离，性能会得到进一步提升。一般的项目到达这一步足以应对大多数的需求。
上面说的系统架构，应用服务器只是被克隆多个然后分别部署不同的，每一台应用服务器上的代码都是一模一样。就像原肆虐我们的病毒，病毒分化后所有的病毒细胞都具有同样的功能，从服务角度上看这种虽然一段时间内可以撑起正常的业务但是服务的可扩展性以及服务的容错性很差，往往增加一个小功能就得大面积发布容易出错，另外从成本控制角度上看耗费了大量得资源。
此时可能出现的问题：
- 软件可用性风险增加。可能一个bug导致整个软件不可用。
- 代码可维护性变差，因为代码量大，逻辑复杂，只有少数老员工能全部理解。代码腐化严重。
- 修改bug和增加新功能会变得困难，可能牵一发而动全身。
- 软件扩展变得困难，新增功能需要考虑是否影响原功能。
- 打包编译会耗时很久，导致发布也很耗时。
接下来我们看一下微服务是怎么改变现状得，不同应用服务器承担的职责开始变化，就像我们的造血干细胞出现让细胞开始分化成为身体各个器官一起协同工作。
我们现在的服务-微服务
我感觉微服务不是一个架构，而是像一个生态，应用与应用之间互相独立，却又彼此依赖。通过 DDD 的模型来设计一个地图，把合适的代码放到合适的地方去。实现微服务涉及的工具太多，以下我采用spring生态来描述整个微服务生态架构，小伙伴可以体会一下。来个宏观图体会一下微服务是啥样的：
如上图整个微服务的生态与周边大概就是这样的。架构也很难一开始就设计的完美，架构不是设计出来的，甚至不能被设计，只能在需求的变化中不断演进。整个架构工作更像药剂师那样对症治病、照方抓药。
软件很大程度上是一个服务行业，虽然长期以来都毫无根据地被错认为是制造行业。这句话对软件行业的描述我觉得十分准确。
微服务优势
- 应用小，可快速编译部署
- 单个微服务维护性变高，修改容易，因为每个团队独立负责一块功能。新功能交付变快，可以快速开发交付
- 扩展性变高
- 可靠性变强，可以部署很多独立的服务
微服务不足
- 整体复杂度变高。
- 微服务变多，怎么监控所有微服务，保证服务稳定，运维变的复杂。
- 分布式数据一致性、分布式事务
- 服务保障一个服务出了问题，如何才能不影响其他服务
微服务这个生态涉及很多周边技术以及需要解决的问题，具体涉及整个微服务生态技术我会在下边简单介绍，但是注意一点不是在项目中使用以下提到的技术就是微服务，而微服务指的是业务之微，技术只是对其进行落地实现；所以我们想要设计好整个微服务架构那么对业务必须十分熟悉，根据业务进行微服务拆分最终辅以技术实现达到最终目的。
微服务架构是为了适应业务的快速变化，产品的快速迭代、交付、反馈和修改而提出的一种架构解决方案。
注册中心（Erurka）
注册中心主要提供三个核心功能：
- 服务注册 服务提供者启动时，会通过 Eureka Client 向 Eureka Server 注册信息，Eureka Server 会存储该服务的信息，Eureka Server 内部有二层缓存机制来维护整个注册表
- 提供注册表 服务消费者在调用服务时，如果 Eureka Client 没有缓存注册表的话，会从 Eureka Server 获取最新的注册表
- 同步状态 Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态。
网关（Zuul）
API网关是一个更为智能的应用服务器，它的存在就像是整个微服务架构系统的门面，所有的外部客户端访问都需要经过它来进行调度和过滤。除了需要实现请求路由，负载均衡及校验过滤等功能外还需要与服务治理框架的结合，请求转发时的熔断机制，服务的聚合等一系列高级功能。 主要核心功能：
- 服务路由转发
- 鉴权校验过滤
- 熔断限制保护
配置中心（Config）
Spring Config首推基于git的管理方式，提供了两个管理维度，一个是label(即branch)，一个是profile。其实他的原理是基于git的变化来通知各个服务的有些不太灵活，以后文章中会采用nacos替换这个config功能，现在先了解一下他是干嘛的就可以了。 主要核心功能：
- 业务配置
- 功能开关
- 服务配置
服务APM（Grafana）
grafana 是一个开源的时序性统计和监控平台，支持例如 elasticsearch、graphite、influxdb 等众多的数据源，并以功能强大的界面编辑器著称。我们可以通过这个平台监控所有服务的负载，流量，使用率，机器硬件相关参数，以及可以配置相关参数通过http或者短信邮件报警提醒等。目前APM工具很多这个只是其中的一种，付费的平台也又很多像听云等平台。
异步队列（MQ）
MQ大家都熟悉，现在主流的MQ有rabbitMQ，rocketMQ，kafka。三者的区别我会在以后的文章介绍对比，以及不同场景应该使用哪种MQ。以及在使用过程中的消息顺序性，幂等性保证等踩坑记录。 核心功能：削峰填谷
容错限流（Hystrix）
它设计用来当分布式系统发生不可避免的异常的时候去隔离当前服务和远程服务、系统、三方包的联系，防止出现级联失败的情况，从而导致整个系统雪崩。 主要核心功能：
- 失败转移和优雅降级
- 实时监控更改相关配置
- 基于线程和信号量的断路器隔离
负载均衡+服务调用（Ribbon、Feign）
ribbon是一个负载均衡客户端，可以很好的控制htt和tcp的一些行为。Feign默认集成了ribbon。ribbon主要功能是提供客户端的软件负载均衡算法。Ribbon就属于进程内负载均衡，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。 主要核心功能：负载均衡
持续集成（Jenkins）
在项目多的时候，重复操作极大的浪费时间。如果遇到同一时间不同项目组打包项目，打包和部署服务器就要排队使用，测试人员只能在等待中浪费时间。为了解决这些问题，选择寻找合适的持续集成方案。来自动化完成重复的步骤。jenkins还包含了很多插件，比如代码校验等等。是CI/CD的基本技术。 核心功能：
- 拉取代码
- 打包构建
- 将资源送往目标服务器
分布式任务调度（Elastic-Job）
它通过弹性调度、资源管控、以及作业治理的功能，打造一个分布式的任务调度总线。 核心功能：
- 弹性调度
- 资源分配
- 作业治理
- 失效转移
分布式缓存（Redis）
这个。。。。还用介绍么。。。多说一句redis这个skiplist跳跃表值得研究一下，另外zset这个数据结构有大用。
核心功能：
- 内存数据库
- 基于内存数据库的各种扩展功能
分库分表（sharding jdbc）
Sharding-JDBC他定位为轻量级Java框架，在Java的JDBC层提供额外的服务，以jar包形式提供服务，无需额外部署和依赖，可以理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。还有个付费的相似中间件那就是阿里的DRDS，有兴趣的伙伴可以了解一下DRDS。 核心功能：
- 数据分片
- 读写分离
- 透明的使用jdbc访问各个数据库
代码托管（Gitlab）
搞开发的相信都知道这个，相当于这个是github的兄弟。
日志收集（ELK）
ELK=Elasticsearch+Logstash+Kibana
- Elasticsearch: 是一个基于Apache Lucene的分布式开源搜索引擎，使用Apache2.0开源协议发布（意味着可以免费下载、使用或者修改）。它在Lucene的实时搜索之外提供了可扩展性、可靠性和多租户功能。Elasticsearch的功能可以通过基于JSON的RESTfulAPI来使用 。
- Logstash 提供了输入插件来支持不同的数据源和平台，设计用来高效地处理日志、事件和非结构化数据源，然后通过输出插件如文件、标准输出。
- Kibana 是一个基于Apache2.0开源协议的开源数据可视化平台。它可以对存储于es的索引中的各种结构化和非结构化的数据进行可视化呈现
容器化（Docker+k8s）
通过 Docker 技术，我们可以像管理我们的应用一样管理我们的基础设施（比如基础依赖等，这里的具体技术其实就是镜像）。通过 Docker 技术，我们可以精简我们的整个开发和交互流程。docker可以做到应用程序和底层基础设施分离，我们可以将这些依赖和应用程序都打包到镜像中，然后测试或者正式上线的时候只需要将整个镜像部署上去就可以了，不需要关心目标服务器上面的基础环境。k8s（Kubernetes ）它可以自动化应用容器的部署、扩展和操作 , 提供以容器为中心的基础架构。通俗的讲就是管理docker的。
等等。。。包括在各个模块中注意的点。我会在以后的文章中分析各个模块的作业和在微服务种的地位以及踩过的坑。想了解的小伙伴记得收藏+关注哈。
