什么是微服务?

微服务就是一些协同工作的小而自治的服务。

一、微服务第一个特性在于“小”

只需要专注做好一件事情,Martin的单一职责原则(Single Responsibility Principle)的论述:把因相同原因而变化的东西聚合到一起,把因不同原因而变化的东西分离开来。这很好的强调了内聚性这一概念。

那么,代码库多小才算小?

代码行衡量代码库的多少是行不通的,因为有些语言表达力强,区区几行代码就道尽了程序员的意图,即代码密度高。

一个比较老套的说法:足够小即可,不要过小。当你不再感觉你的代码库过大,可能它就足够小了。

另一个回答服务应该多小的关键因素是,该服务的大小是否能很好的匹配团队结构,如果一个小团队不能很好的维护该服务,可能服务还可以再拆分为更小的。

二、自治性

微服务的第一个特性在于自治性,一个微服务就是一个独立的实体,可以独立部署在PAAS,也可以作为一个操作系统进程存在。

自治性对应的是耦合性低,有一个黄金法则:如果能修改一个服务并部署,而不会影响其他任何服务,那么系统就很好的解耦了。

三、微服务的主要好处

1. 技术的异构性

每个微服务可以各自使用不同的技术栈,包括但不限于编程语言、数据库,这使得不同微服务能选用最合适的技术栈来实现,大大提高了灵活性。

什么是微服务?_第1张图片

 2. 弹性

假如一个微服务不可用了,其他微服务还能正常使用,这是因为微服务之间是隔离的。

每个微服务都运行在多台机器上,确保可用性,进行弹性伸缩,保证高峰和低谷时的访问需求和运维成本。

3. 扩展

对于单体服务而言,假设某个组件有性能问题需要升级,那整个服务都需要升级到下一个版本。

而对于微服务而言,某个微服务有性能问题,只需要升级该微服务,而不影响其他微服务的正常运行。

4. 简化部署

对于单体服务,即使变更了一行代码,也需要部署整个应用程序,由于单体服务体积庞大,构建部署都会比较耗时,因此,开发者在两次发布之间往往会有很多功能增强,这意味着一次要发布大量的变更到生产环境,而发布的新代码行数越多,出错的概率也越大。

微服务就把问题简化了,变更一行代码只需要发布一个微服务相关的一批机器,而发布大量代码时,即使出了问题,也可以快速回滚一个微服务。

5. 与组织架构相匹配

一个团队负责维护若干微服务。

6. 可组合性

微服务能很大程度保证重用已有的功能。

7. 对可替代性的优化

假如有一个代码量庞大的(数百万行代码)、使用古老的Fortran语言变体写的遗留系统,需要重写,这时候采用微服务的方式替代,也是一个不错的方案。

四、没有银弹

No Free Lunch Principle原则说明了,任何新鲜事物带来好处的同时,也会有相应的代价,微服务也不例外,在带来上述好处的同时,微服务也存在缺点,那就是微服务之间的调用关系变得异常负杂,这也在提醒我们,拆分微服务时也不能过小,过小则微服务数量巨多,关系也就更加复杂了。

你可能感兴趣的:(微服务,微服务,java,架构)