Java之微服务浅谈

微服务近年来如火如荼，很多公司都在考虑或尝试微服务架构，随着微服务的容器化部署的发展，加快了微服务架构的兴盛。

• what：什么是微服务架构
• why：为什么引入微服务架构
• how：如何进行微服务拆分
• when/where：什么情况考虑微服务架构

1、what
分布式时代，系统间需要打通、组成集群，从而具备更强大的吞吐能力。将一个单体项目拆分成多个微服务，各个微服务之间打通、相互协调，从而完成全流程服务。微服务是一种架构风格，是架构设计层面的，分布式是一种系统的部署方式，是部署层面的。

• 分布式系统：分布式系统一定是由多个节点组成的系统，其中节点指的是计算机服务器；这些节点是互通的，将一个大的系统划分为多个业务模块，业务模块分别部署到不同的节点上，各个业务模块之间通过接口进行数据交互，对于用户而言，就是一个系统，实际上是通过背后众多节点提供不同服务而组成的一个分布式系统。
• 集群：集群是指在几个计算机服务器上部署相同的应用程序来分担客户端的请求，它是一个系统部署在不同的节点上。
• 微服务：微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务。微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。微服务是以开发一组小型服务的方式来作为一个独立的应用系统，每个服务都运行在自已的进程中，服务之间采用轻量级的HTTP通信机制 ( 通常是采用HTTP的RESTful API )进行通信。这些服务都是围绕具体业务进行构建的，并且可以独立部署到生产环境上。

分布式好比多个人一起做不同的事，集群好比多个人一起做同样的事。
微服务相较于分布式来说，细粒度更小，服务间的耦合度更低，并且可以说微服务一定是分服务分开部署的，所以其实微服务是基于分布式的，更像是对分布式系统的一种优化。
2、why
传统的系统应用为单体架构，在系统的初期，只是希望能尽快的将项目搭建起来，方便将产品更早的投运进行验证，这种架构在开发初期确实给开发和运维带来了很大的便捷。优势有，开发直接，代码和项目集中式管理；只需维护一个工程，运维成本低。
但随着业务和功能越来越复杂。开发团队的规模越来越大，单体架构的缺陷慢慢体现出来。劣势有，在数据库层面，连接数成为应用服务器扩容的瓶颈，比如mysql的客户端数量是有限制的；研发的成本抑制了研发效率的提升，研发团队小伙伴很多，共同维护一套代码，在配合的过程中，沟通成本大，如需要一个发送短信的功能，那么有的研发同学会认为最快的方式不是询问是否有现成的，而是直接自己写一个，会造成结构混乱和重复开发。单体架构的运维成本高，项目初期代码功能少，后面代码多而复杂，任何小的改动都需要构建整个项目，打包、部署非常不灵活。
这些问题随着微服务的出现，通过服务化的拆分来解决。

• 服务拆分后，微服务的各个服务可以独立并行开发、测试、部署，代码规模越大，微服务的优势越明显。
• 各个服务独立运行，通过进程的方式隔离，控制故障的影响范围，进而保证应用的稳定。
• 若是某个业务需要独立的技术栈，可通过服务拆分，接口继承的方式实现。
• 微服务将业务分解为更多的服务，业务边界更清晰，更容易把一个复杂的问题分解为简单的小问题。

但由于服务数量变多，微服务架构需要额外考虑服务的注册发现、路由网关、治理等问题。由于架构变复杂，研发人员既要考虑数据库设计，又要考虑接口定义，对研发人员的水平要求更高。对各个服务的监控、健康监测要求更高，整体运维复杂度更高。

3、how
引入微服务架构后，进行服务拆分的指导原则如下。

• 单一服务内部功能高内聚低耦合，即灭国服务只完成自己职责内的任务，对应不上自己职责的功能交给其他服务来完成。
• 闭包原则，即当改变一个微服务的时候，所有的依赖都在这个微服务组件内，不需要修改其他的微服务。
• 服务自治，接口隔离，即尽量消除对其他服务的强依赖，降低沟通成本，提升服务的稳定性，通过接口隔离，隐藏内部实现细节，使得服务可以独立开发、测试、部署、运行。
• 持续演进原则，在服务拆分初期，其实很难确定服务究竟拆分成什么样，应逐步划分，持续演进，避免服务数量的快速增长，先拿出几个不太重要的功能划分出来做实验，若出现故障，则可以减少故障的影响范围。
• 切勿影响日常功能迭代，一边做产品功能迭代，一边完成服务化拆分。比如优先剥离比较独立的边界服务。
• 避免环形依赖与双向依赖，尽量不要有服务之间的环形依赖或双向依赖，原因是存在这种情况说明我们的功能边界没有化分清楚或者有通用的功能没有下沉下来。
• 拆分粒度，平衡拆分粒度可以从两方面进行权衡，一是业务发展的复杂度，二是团队规模的人数。推荐三个人分配一个服务，符合弓箭原理和三个火枪手的原则。
  微服务拆分的落地还要提前准备好配套的基础设施，如服务描述、注册中心、服务框架、服务监控、服务追踪、服务治理等几大基本组件，以上每个组件缺一不可，每个组件展开又包括很多技术门槛，比如，容器技术、持续部署、DevOps 等相关概念，以及人才的储备和观念的变化。微服务不仅仅是技术的升级，更是开发方式、组织架构、开发观念的转变。

4、when/where
项目初期，应以单体架构优先。随着应用的推广，为了丰富系统的功能、抢占市场，开始引入更多的同学，这时系统的复杂度越来越高，就出现单体应用和团队规模之间出现的矛盾，研发效率不降反升，类似单体一条线，微服务一条线在坐标系图上出现交叉，表名业务已经达到了一定的复杂度，单体应用已无法满口快速发展的需求，这时就需要考虑进行服务拆分，这点需要综合考虑，根据公司的具体情况。

5、注意
微服务化，需要考虑研发团队是否有足够的经验，能否驾驭微服务的技术栈。也并不是要求团队必须是经验丰富才能启动微服务化拆分，若有微服务专家固然最好，若没有就需要先进行充分的技术论证和预演。
由于个人的认知是有限的，只能基于目前的业务状态和有限的预测来制定出一个相对合适的方法，而不是最优方案，需要时刻做好调整的准备，因为随着业务的发展，需要重新审视服务的划分是否合理。
微服务架构需要行动，而不只是理论，在具体怎么拆分，也不要太纠结，不动手怎么知道是否合适？若是拆了之后发现不合适，及时调整就好了，注意提前对微服务的组件进行调研、应用、预演，对服务化搭建起一套完整的能力体系。