34 | 深入理解微服务架构：银弹 or 焦油坑？

我们公司的实践是比较粗粒度的子系统或服务，基本上没有太细粒度的微服务，以webapi为主。感觉更像微服务架构，只是服务粒度比较粗，从概念上算是SOA还是微服务架构呢？

对于一个新事物的诞生，本能地套用已有的知识。特别是一个并不简单的东西，这算是一种高效的入门方法。微服务架构其实相当复杂，我是分成好几个阶段理解。 1、第一阶段，微服务架构就是去掉了ESB的SOA架构，只不过是通信的方式和结构变了。对于初级的使用者而言，这样理解没有太大问题。 2、第二阶段，没有了ESB，原本很多由ESB组件做的事儿，转到服务的提供者和调用者这里了。他们需要考虑服务的拆分粒。大体仍然算是SOA架构。 3、第三阶段，随着服务的数量大幅增加，服务的管理越来越困难，此时DevOps出现了。这个阶段的微服务架构，已经是跟SOA架构完全不同的东西了。 之前给一家大国企分享过一些经验。他们想从传统架构，转向微服务架构。 1、建设好基础设施，RPC、服务治理、日志、监控、持续集成、持续部署、运维自动化是基本的，其它包括服务编排、分布式追踪等。 2、要逐步演进和迭代，不要过于激进，更不要拆分过细，拆分的粒度，要与团队的架构相互匹配。（康威定律） 3、微服务与数据库方面，是个很大的难点，可以深入了解下领域驱动设计，做好领域建模，特别是数据库要随着服务一起拆分。 说完上面这些，他们的研发负责人说，我说的跟他们的架构师说的不一样，他们的架构师说，微服务就是各种拆分，不顾一切地拆分。

我们是一家社交公司，后端加厚的演变符合dubbo官网的那张图，在Mvc架构坚持了一年后，业务越来越大，工程越来越臃肿。后面我们一致同意进行服务话，开始用了dubbo。后面由于决策层的原因没有上，后面来了个架构师，又重启了服务拆分，到现在已经用于生产。我们使用的是Spring cloud，现在拆分暴露了很多问题: 1、个别服务没有熔断出来，出现过雪崩效应 2、服务拆分过细，服务调用链过长 3、开发人员能力不一样，代码水平不一样 4、没有监控措施 5、每个服务部署多台，日志查询就会死人的感觉 6、开发过程中经常出现访问不到该访问的接口，这是因为开发人员经常启动本地服务，就会导致30%的概率访问不到 7、使用了不合理的持久层框架，使用了JPA访问 大概就有上面的问题，总之微服务不是银弹，用得不好会发现无穷无尽的坑。当然，出现问题解决问题就是了。唯一的就像CEO说的: 你们他妈的是完全在拿用户当小白鼠使用

我们目前全部微服务，踩坑踩了不少，拆分服务同时要把自动化运维系统和多维度监控系统，包括问题定位跟踪系统建立起来，要不然拆了就是噩梦。

说到微服务，切分的粒度和基础设施都致关重要。 经历的项目有创业初期的单体服务，也有不太完善的服务切分的系统，也有微服务基础设施相对完善的公司。 单体服务致命就致命在随着项目的发展，项目会越来越臃肿，越不利于扩展开发。 微服务过程怕就怕基础不完善，人员配备不够盲目切分，导致工程师开发和维护的战线拉长，特别疲惫和泄气，容易产生一种抱怨的大气氛，从而导致微服务失败，重新合并一部分服务。 微服务做的好的，也有所经历，公司的基础设施完全云化和统一管理，申请几台机器，一套缓存集群，一套mq，sql/nosql…特别容易，工程师愿意建独立的工程，因为很容易构建和部署。这种感觉有点像svn和git，git建分支特别轻量，大家都愿意用分支管理自己的代码，迭代开发，应急处理都能自由切换，得心应手。 现在遇到一个问题，就是微服务内部系统大多使用rpc，但对接外部系统，或者跨外网传输到客户端就需要http-rest类的协议。也就是我们常说的网关，如果是纯http就很容易做到通用的转发机制，但是http转rpc就不知道有什么方式可以做到通用转发了，内部每增加一个rpc，网关就需要增加一个对应的服务处理逻辑。不知道，这个问题，有没有好的解决办法？

让我想起了一次面试经历，一家小公司，技术团队大概7 8个人，然后他们要进行微服务架构改造，我问他们:你们这样满足康威定理么？他们一脸懵逼……我就果断闪人了

我们的业务也算是微服务吧， 接手项目时，已经有好多服务，主要采用的语言有java，php，nodejs，存在以下问题： 1、没有一个统一的网关服务，前端请求后端服务都需要后端的服务A来充当安全校验，权限校验等，A服务充当了多重职责，变的职责不明确了，后来抽出网关系统，负责平台统一的流量入口。在构建微服务网关系统是至关重要的。 2、监控系统不完善，调用链跟踪，异常报警都不完善，对微服务是巨坑，查找问题如同一场噩梦，调用链很长，一旦发生异常不知道到底哪里出现问题，得一个一个去找。后来慢慢完善，变得好了很多，问题很快定位。 3、加入网关后，没有一个统一的服务发现注册中心，网关的路由依靠人工手动配置，变的很麻烦，也很容易出错。后来引入consul，得到改善。

我们公司的平台就是使用微服务架构，十多二十个微服务，但是没有自动化部署，监控，自动化测试这些，而且每次报错日志也特别难找，但是我们那架构师却不重视这些，只想继续升级平台的功能

我们之前5个人的小团队，老板一拍脑袋玩起了微服务。整了spring cloud那一套全家桶： 现有业务拆拆拆，什么注册中心，配置中心，链路追踪，网关，ELK统统往系统里面堆。 主要的带来了以下问题： 1、运维成本过高，部署物数量多、监控进程多导致整体运维复杂度提升。 2、接口大量的兼容版本 3、网络延迟，服务容错，可用性，负载复杂性大大提升 4、还引入了分布式事务 团队没有运维，我们只能硬着头皮上，自己用docker搭redis集群，mysql集群，mq集群，es集群 最终因为不够钱买服务器，整个叫停了，哈哈哈哈哈

我们项目之前是把数据采集，和展示都是我们Java组去写的。后面公司为了统一，把采集部分交给了.net组。我们Java只负责数据展示。但是我们这边又按照领导的要求把整个业务拆分为模板解析层-》api层——》终端层。现在每次最烦的事就是找bug。一直感觉现阶段我们的任务和目标没有这么庞大，这与架构中的简单和合适原则想违背。搞的整个项目组一直在反复的开发工作中。都很心累