分布式系统的那些事儿（七） - 微服务架构体系

微服务的出现，标志了又一个新的里程碑，似乎你不知道微服务就代表你好像out了一样。微服务是业务服务化，将SOA更好的延续了下去。配合restful也能够更好的提供api接口。

简单来说就是微服务把各种各样的小的服务区分开来当做一个当度的应用跑在服务器上，并且他的通信机制也是十分简单的，使用rest或者rpc都行。他们可以各自对自己的业务进行处理。各个服务直接可以用不同的语言开发，这样提高了不同技术团队之间的职能。

微服务的特点：

1、微服务的组件是以服务的形式存在的。

2、由各个不同的业务来切分整个大服务。

3、微服务是产品，不是项目。微服务在整个开发生命周期十分长久，并且需要后期团队的维护，就是因为微服务的特性，才使得维护更加的方便。

4、简单的通信机制，不论是rpc还是restful，都简化了系统服务之间的访问，并不像曾经的wsdl那么复杂。

5、分散治理，这个就是跟传统巨石应用区别开来了。不同的服务都是一个很小的组件，那么在组装的时候不同的服务可以组装成不同的微服务，十分灵活。

6、数据库分散管理，在做巨石应用的时候，一个项目就是访问一个数据库。那么微服务不是，每个不同的业务访问并且管理的都是自己的数据库，与各个不同的服务之间的数据库是不同的，这样也做到了数据的隔离。

7、容错性，每个服务宕掉不可访问的时候，微服务可以为每个服务进行监控与恢复。

其实我们平时接触的最多的还是SOA，SOA是偏向系统的解决方案，而微服务面向服务，微服务的颗粒度要小很多，SOA比较大，哪怕是一个小更新其实也是要重启对应的系统，而微服务却不是。考虑一下玩王者荣耀的时候，可以不停机更新，是不是一个道理？

​SOA的缺点：

随着时间的推移，代码库会越来越大，如果团队来了一个新人是十分恐惧的。

开发工具也会随着代码量的增多变得缓慢，这样导致的就算是开发效率的降低。

服务器启动变慢，代码变多，容器在加载的时候读取的代码文件也越多，这样导致容器每次启动都会比较慢。

持续部署相对复杂，不利于运维更新。每次更新整个系统必须关闭，用户无法访问。

可扩展性降低。

微服务的特点：

各服务之间通过json或者xml的数据形式通信。把一组类似的功能或者业务作为一个单独的微服务来做。比如订单服务让订单核心团队来维护。cms由cms团队来维护。

服务之间通过rest或者rpc来通信，甚至使用消息队列。

服务独立开发和部署，相互不影响，技术只能部门也相互不影响。

服务之间相互解耦，每个服务都有自己对应的数据库。注意，这需要做好数据一致性，比如tcc。

每个服务独立部署，对于频繁更新版本的项目由很好的效率。

便于扩展团队和组织架构。

整个微服务相对技术难度比SOA加大，需要开发人员对技术有一定的持续投入。

分布式事务比单体应用难处理。

生产环境部署复杂度提升，需要运维人员有一定的功底。

微服务的难点：

很多初创型公司对于开发进度是十分有要求的，起初并不会使用微服务架构，而是单体应用或者SOA，为的是更好更快速的发展自身的业务。然而发展到一定规模后，整个技术架构发生变化，要重构为微服务，这个时候的技术选型以及如何重构，和整个团队技术人员的参与就相对来说是个难点了。