基于分布式架构上的微服务架构设计

微服务

什么是微服务

1. 为了降低代码的耦合性,将项目进行了拆分.按照功能模块拆分为若干个项目.该项目称之为服务.(分布式思想).
2. 如果采用微服务的结构,要求服务器如果出现了故障应该实现自动化的故障的迁移(高可用HA)

单体架构的不足

在文章网站后台主流架构一文中，我较为详细阐述了分布式架构的设计模式。

而这之中我们不难发现，后台业务处理为单体架构，单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多：
1.复杂性逐渐变高

比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。

2.技术债务逐渐上升

公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。

3.部署速度逐渐变慢

这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。

4.阻碍技术创新

比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。

5.无法按需伸缩

比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。

6.基于单体架构拆分的服务在故障迁移方面不能实现高可用（负载均衡、反向代理时也需要手动修改配置文件）

微服务与单体架构区别

单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。

单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。

单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

微服务架构的使用

而微服务架构便是在此分布式架构的基础上，利用SOA思想，将业务服务器集群按功能模块进行拆分，从而增加业务修改的便捷性。

SOA思想

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

微服务架构机制

步骤：
1.服务提供者启动时,.将自己的信息注册到注册中心中.
2. 注册中心接受到了用户的请求之后,更新服务列表信息.
3. 当消费者启动时,首先会链接注册中心,获取服务列表数据.
4. 注册中心将自己的服务列表信息同步给客户端(消费者)
5. 消费者接收到服务列表数据之后,将信息保存到自己的本地.方便下次调用
6. 当消费者接收到用户的请求时,根据自己服务列表的信息进行负载均衡的操作,选择其中一个服务的提供者,根据IP:PORT 进行RPC调用.
7. 当服务提供者宕机时,注册中心会有心跳检测机制,如果检查宕机,则更新本地的服务列表数据,并且全网广播通知所有的消费者更新服务列表.

通过以上架构，我们不难发现微服务架构的核心之一便是注册中心的搭建。如Zookeeper等。