架构新起点

架构？？？？

从一开始学习 JavaEE 开始，最开始听到的便是三层架构+MVC。我认为的架构，是整个项目的结构，由项目中的各个组件组合而成，就像是积木拼搭在一起支撑起整个体系结构，而架构的目的就是为了解耦，以至于使用各种开发框架。

微服务

微服务是一种新型的架构风格和架构思想，从2014年开始被人们所关注。

由于互联网发展迅速，传统的单体架构无法承受大流量导致的高并发问题，经过这么多年的架构演变，更多能够支撑高并发的架构不断出现，例如 SOA 架构（面向服务），以及微服务架构。

在我看来，微服务架构更像是 SOA 架构的升华，相比于 SOA 架构，微服务架构从字面上更注重“微”。SOA 将服务抽取合并到同一层中（服务层），但是这并不符合“高内聚，低耦合”原则。

微服务架构能够更好的进行分布式系统开发，它注重的是将整体业务组件化，将单体项目按照多种拆分方式拆分成一个一个独立的服务，每一个服务就是一个项目，可以独立部署运行。

问题

既然微服务架构将单体应用进行拆分，单独部署运行，那么必然会面临一些新型问题，这也是微服务架构需要解决的四大问题。

1.这么多服务如何管理

将单体应用按服务拆分，通过不同程度的拆分粒度，可能拆分出几十甚至几百个服务。那么，这些成百上千的服务，没有一个统一的管理是肯定不行的，如果没有一个管理者将其全部监控管理，那么即使能够部署成功，在运行过程中出现的问题也不可能发现。

2.服务如何访问

浏览器访问项目通过ip地址，但是在部署这么多服务的情况下，每个服务的ip地址都是不相同的，我们不可能让浏览器或者用户记住每个服务的ip地址，那么这么多的服务要怎么让浏览器统一的访问也是个重要的问题。

3.服务与服务之间如何通信、调用

从微服务的拆分来看，拆分出来的每个服务都是单独独立运行的，服务与服务之间没有任何的关系，但是，项目中可能存在这个服务需要调用另一个服务功能，便出现了服务与服务之间相互调用的问题，应该怎么调用才是最好的。

4.服务崩溃怎么办

在高并发、大流量的情况下，服务总会有支撑不住的时候，服务宕机问题也是需要实时监控的，以便在第一时间进行修整。

我认为，微服务架构属于包含松耦合分布式组件的系统结构，提供了一种新型的、更清晰的架构思想，进行项目的拆分的确很大程度的降低了项目中的耦合度问题，但是有利有弊，在降低耦合度时发生的上述四种问题也是需要解决的，如果能够很好的解决微服务的四大问题，我觉得微服务架构在将来会有很大的发展。

以上都是作者本人在学习微服务架构过程中自我理解的，如果有误，请指出共同进步。