微服务 -开篇

互联网的高速发展，产生了一系列的技术革新。微服务也算是其中一员。

微服务算是一种风格，是为了解决互联网运营中产生的问题，而出现的，是一种问题解决方式。现在大部分互联网企业或者想扩展互联网业务的企业，都在将微服务或者更直接的，spring cloud 作为首选的架构。当然这也符合spring团队的目标，他们的目标就是使spring cloud 成为微服务架构落地的标准。当然spring cloud 是java原生开发，对java的支撑更为全面。随着sidecar模式的出现，spring cloud 也可以对接各种语言实现。

但有一点，我想说明，一个系统或应用，它都应该有明确的目标定位。尤其是在项目交付中，一个用户量总体几百，并发量几或几十，功能点也有限的系统，我们不应该为了追求技术而使用技术，技术是实现业务的工具。这跟充实自己的技术，钻研新技术不矛盾。我们应该以目标（业务或需求）为导向，分析其整体的资源依赖。架构的发展历程经历了单体、分布式、SOA到现在的微服务。但这并不意味着新出现的架构就一定优于旧的架构。切记。

最近跟一些朋友交流，提及某些业务解决方案的时候，好些都把spring cloud 作为了首选，这感觉有点像盲目的崇拜。任何事物都有两面性，作为架构来说，这个工具或架构的两面性需要关注的更深，因为如果是一个平台运营公司，它可能会制约后期战略的执行，也可能会导致公司在转型时产生更大的冗余或失效资源。

下面简单的描述下各阶段架构的一些特点：

单体架构：

单体架构的好处很明显，开发方便、测试简单、部署容易、维护也比较容易。

随之而来的缺点：

一旦有更改，整个应用服务可能会需要重新部署，如果是单点，可能会导致一段时间所有服务都无法正常使用。

因为开发中可能存在的耦合，在改动某个服务的功能时，对其他的服务项也产生了影响，有牵一发动全身的可能。

在开发时，也是因为代码的耦合，导致了开发团队的耦合，会有一些阻塞的行为发生，团队的灵活性要差一些。

分布式架构：

分布式架构对业务进行垂直切分，降低了各个模块之间的耦合，各个模块可以在独立的进程中运行，系统的开发灵活度上升，提升了模块的复用程度。

随之而来的，分布式对网络的依赖程度上升，部署的复杂度上升，开发的工作量上升。对资源的依赖上升。

SOA:

SOA，面向服务架构，其实也是分布式架构的一种，具备分布式的优缺点，另外，可以让不同的业务建立不同的服务，不同服务的负载不同，继而匹配不同的计算资源，同时，业务逻辑可以定制组合。

微服务：

微服务可以说是SOA的延伸或者说是更规范、更系统的方法论。

后面会详尽的介绍微服务，这里就先不细说它的优缺点了。