谈谈架构和微服务（上）

作者｜GabrielChen

编辑｜包包  

不知从何时起，与同事，面试者，面试官谈起架构理念，总是绕不开微服务。甚至有时候听到这三个字的时候，脑壳会痛，相似的还有中台, 总觉得是旧瓶装新酒。当然此时的盛行是有其原因的，猜测主要原因是容器化的盛行。

架构和微服务的定义：

能给出合适的定义才能表明一个人真正理解了所描述的事物。

架构：

按照一定的方法设计出来，把系统划分成颗粒合适，边界分明，复用合理的模块。这里的关键词是颗粒合适，边界分明, 合理复用。

微服务：

颗粒度较小的架构，关注点是颗粒度相对较小。

为什么要存在架构和微服务架构：

大部分事物存在的理由都是带来了价值或者解决了问题，架构或者架构师存在的意义也是解决问题。合理架构带来的直接帮助是节省了因为改动引起的工时变化。(改动 这个关键字圈出来。) 当然还有一部分是带来性能的提升或者是安全性。

假设架构师或者业务的owner对业务没有太多的前瞻，那么业务初始的必然是一个大应用。随着时间的推移会慢慢发现大应用的问题：

1. 一个团队难以维护这么的系统，理解和沟通麻烦，出现边界不清大量扯皮。

很多人都会说用写文档解决问题，一方面高强度的开发，和利他主义薄弱的个体难以主动维护文档。另一方面读文档也存在理解偏差的情况。所以一个系统要让别人理解，最好设计本原就是好理解的。

2. 系统之间互相影响，工程效率/测试效率，安全性也受到影响。

一个核心系统与非核心系统，无论是发布还是出现问题的报警处理级别都是不一样的。因为一个后台管理系统发布或者出bug导致支付业务挂了, 就会让外界感觉匪夷所思。因为要保证核心功能不受一些非核心的影响，每次发布重新覆盖所有流程。

所以我们出现微服务就是为了解决上述问题。

- - - -未完待续- - - - 

喜欢本文的朋友，欢迎关注公众号  并发编程网，收看更多精彩内容