【架构】了解微服务

一、前言

      近些年微服务是越来越应用广泛了，去年的时候丹姐出去面试，面试官问过她有没有用过微服。当时自己还没有建立一个服务的概念 ，瞬间懵逼了。但是后来回想，现在自己的系统也是发布了很多的服务，每个服务都算是一个微服务。

二、什么是微服务

      微服务（Microservice）虽然是当下刚兴起的名称，但是本质上来说，微服务并非什么新的概念。实际上，很多SOA实施程度比较好的公司，已经在使用微服务了。只不过，他们自己使用，并不介意是否有一个时髦的名词来描述表示SOA已经发展到了微服务。

      微服务其实是服务化思路的一种最佳实践方向。之所以交微服务，是与之前的服务化思路和实践相比较而来的。早些年的服务实现的思路是将很多功能开发并交付都打包到一个很大的服务单元（Monolith），而微服务实现思路更加趋向单一，服务单元小型化和微型化。

      所以，在思路和理念上，微服务就是要倡导大家尽量将功能进行拆分，将服务粒度做小，每个服务可以单独的承担对外服务的职责，沿着这个思路开发和支付的软件服务实体就叫做“微服务”。

      您可能会问，原来将很多功能打包到一个很大的服务单元进行交付不能满足需求吗？

      实际上，并非原来的服务“大一统”（Monolish）实践不能满足要求，也不是不好，只是他有自己存在的合理场景。对于Monolish服务来说，如果团队不大，软件复杂度不高，那么，使用Monolish的形式进行服务化治理是比较合适的。

      但是，随着软件系统的复杂度持续飙升，软件交付的效率要求更高，投入的人力等资源越来越多。为了减轻复杂，我们自然会将项目按照要开发的功能拆分为不同的项目，负责不同研发服务的研究人员，可以并行操作。

三、微服务带来的好处

• 独立、独立、独立

      每个服务基本上都是独立的项目，带来的明显的好处，第一个就是可拓展性。微服务可以快速的添加服务集群的实例，提升整个微服务集群的服务能力，而在传统的模式下，为了提升服务能力，很多时候必须强化和拓展单一节点的服务能力来完成。如果单个节点服务能力已经达到极限，再寻求拓展的话，得从硬件整体下手。

• 多语言生态

      微服务的提供者既可以使用java或者GO等静态语言完成微服的开发和交付，也可以使用python或者Ruby等动态语言完成微服务的开发和交付

四、微服务会带来哪些挑战

      微服务给我们带来的并非只有好处，还有一些挑战。

• 服务之间的治理

• 硬件设施负载增加

• 增加一种语言生态用于微服务的开发和交付，是否需要重新搭建一套研发测试环境。

五、小结

      微服务话虽然是当下的流行趋势，但是并非任何场景都合适，我们要慎重考虑“大一统”和微服务架构。而且一旦确定选择了微服务化之路，那么就应该围绕团队和组织的主要语言生态以及微服务方向积极搜素高效的开发和交付方式。