DreamSun的博客

虽然说牛逼的公司都有那么几个牛逼的运维团队，牛逼的运维团队都有着神秘黑科技般敲代码的姿势；本人虽然不是一个运维工程师，但是有幸自己比较爱倒腾这些东西，也会那么一点点运维知识，虽然不算专业，但是还是可以在linux平台下敲一敲代码。去年由于自己业余时间搞了一个app项目，当时自己兼任后端开发，又同时兼任运维，经过多少个夜晚才把后端API网关 搭建起来，当时技术选型主要使用微服务架构，说到微服务架构，也就少不了分布式集群，那就更少不了Consul。

互联网的快速发展，微服务架构已经成为了后端人员一个必备技能，今天我们就来分享微服务中四种常见架构模型，帮助我们更好的去了解微服务的发展。微服务的几种模型见证了微服务架构的演进历史，每种架构都有其使用场景和一定的时代意义；四种架构都是分离关注点，将变与不变进行分离；四种架构模型表现形式不一样，但设计思想都体现了微服务架构高内聚低耦合原则，正所谓神同行异；四种架构的核心层都是领域层，它保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务；

服务发现是⼀个古老的话题，当应用开始脱离单机运行和访问时，服务发现就诞生了。目前的网络架构是每个主机都有⼀个独立的 IP 地址，那么服务发现基本上都是通过某种方式获取到服务所部署的 IP 地址。DNS 协议是最早将⼀个网络名称翻译为网络 IP 的协议，在最初的架构选型中，DNS+LVS+Nginx 基本可以满足所有的 RESTful 服务的发现，此时服务的 IP 列表通常配置在 nginx或者 LVS。

将系统的业务功能划分为极小的独立微服务，每个微服务只关注于完成某个小的任务。系统中的单个微服务可以被独立部署和扩展，且各个微服务之间是高内聚、松耦合的。微服务之间采用轻量化通信机制暴露接来实现通信。那么微服务可以怎么拆分呢？

随着业务量增长，单表的数据量达到性能瓶颈之后，我们就要采用分库分表来对数据库表进行水平拆分和垂直拆分了，具体如何进行合理的拆分，以及技术选型，这些和项目现有的表结构设计是息息相关的，要考虑后续的可拓展性，不能短期拆了一时爽，后续业务量增暴涨之后，服务器的性能不足以维持数据库的性能时，这时候要拆分服务器部署了。不管单体服务，还是微服务，数据持久层都是必须的，我们是选用互联网项目经常使用的mysql作为DB，为了保证服务读写效率以及高可用性，我们主从分离模式，同时实现读写分离，来保障mysql的读写性能。

数据库中的数据是共享资源，因此数据库系统通常要支持多个用户的或不同应用程序的访问，并且各个访问进程都是独立执行的，这样就有可能出现并发存取数据的现象。这里有点类似Java开发中的多线程安全问题（解决共享变量安全存取问题），如果不采取一定措施会出现数据异常的情况。列举一个简单的经典案例：比如用户用银行卡的钱还平台账户钱，银行卡扣款成功了，但是平台因为网络或者系统问题没有还款成功，就会出大问题，这时候我们就需要使用事务。

配置中心的思路是把项目中的配置参数全部放在一个集中的地方来管理，并提供一套标准的接口，当各个服务需要获取配置的时候就来拉取信息，当配置中心有更新的时候，也能通知其他服务，实时同步最新消息。补充一下单点服务器Consul集群的步骤，我的虚拟机ip 192.168.88.144,配置3个节点, Consul v1.12.1。server1 basic.json详细参数,执行命令。server2 basic.json详细参数,执行命令。server3 basic.json详细参数,执行命令。

缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，自由灵活，更符合为服务理念。通过上面的方式我们解决了微服务之间的相互调用，但是存在硬编码的问题，如果服务提供者的地址发生变化，就需要手工修改代码；（1）RPC远程过程调用，类似的还有RML。Feign是Spring Cloud提供的一个声明式的伪Http客户端， 它使得调用远程服务就像调用本地服务一样简单， 只需要创建一个接口并添加一个注解即可。这个时候就会需要服务治理，服务治理是微服务架构最核心的问题，用于实现各个微服务的自动化注册与发现。

什么是微服务？维基上对其定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，将应用程序构造为一组松散耦合的服务。在微服务体系结构中，服务是细粒度的，协议是轻量级的。微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务通常● 有自己的堆栈，包括数据库和数据模型；● 通过REST API，事件流和消息代理的组合相互通信；● 和它们是按业务能力组织的，分隔服务的线通常称为有界上下文。尽管有关微服务的许多讨论都围绕体

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。