微服务

从0开始学微服务

 

学习微服务之前，我想了我做过的项目，复杂的耦合，繁重的单体应用。之前用过dubbo进行服务模块子项目。算是有点微服务的基础吧。接下来我会逐步的写出我对微服务的理解及相关技术应用。

单体应用

常见的LAMP(Linux+Apache+Mysql+PHP) 以及MVC(spring+mybitis/hibernate+tomcat),随着业务量增加，项目越来越多，越来越繁重，每次升级更新，日常维护，甚至于服务器的优劣都对该项目进行了影响。

服务化

常见的项目太大，进行项目拆分，把一个独立的业务拿出来，成为一个子系统。庞大的项目就是有这几个小系统组成的。

微服务

在我看来，微服务进行了粒度更细的服务划分。甚至服务划分不同的等级。

 

我个人看来，项目拆分，进行服务化，是项目到达了一定的瓶颈，可能是系统瓶颈无法承受过多的访问，可能数据库读写缓慢；也可能是日常维护人工成本太高。但对一个项目而言，过于膨胀，拆分是必不可少的趋势。

下面是我从网上找的架构图。

从图上可以清晰看出不同层次的设计。

这里也就延伸到拆分的两个手段：

1.横行拆分（业务拆分）

业务拆分也是最为常见的一种方式。例如我做的商城项目，用户订单模块是在支付完成后生成的，同时需要和卖家，物流打通。 这个商场的购物功能是耦合不大的，是完全可以独立出来的模块，作为一个子系统。

根据项目的业务独特性，找到合适的点进行业务拆分，是常见的。

 

2.纵向拆分。

纵向拆分很多人不太理解。 假设这么一个场景，商城项目刚上线，运营活动，以及红包，抢货促销场景居多，数据库的并发吃不消，我们打算用redis去做，但又不是临时使用redis.所以我们对数据读写存储这一层拆为一个子系统，作为底层的数据存储层。 这一层用了mysql,redis,es但是对调用它们的业务来说是无感知的。

 

 

但是纵向拆分是很麻烦的，代码层面改动大。设计业务多，难以测试。所以一般情况是定位到系统瓶颈针对某一点优化，或者开始业务拆分，如果要想纵向拆分，必须提前看到半年后的运营情况项目情况，然后拆除不必要的业务代码，在不断进行重构测试的情况下逐步把业务剥离出来。

 

拆分为各个子模块后，各个服务之间怎么调用，怎么协调，出问题了怎么办，等等具体的细节。

微服务架构不断发展也是因为现有的技术栈，技术案例是可行的。现有的微服务大致分为以下几个部分，分别解决不同的问题。

1.服务描述

2.注册中心

3.服务框架

4.服务监控

5.服务追踪

6.服务治理