为什么需要微服务？
不是为了微服务而微服务，微服务需要依托业务和组织架。所谓是强扭的瓜不甜，还特别扭。回顾下当前自己工作的公司，业务服务公司基本使用的是分层集群架构，老一点的web应用层里面封装函数和方法，几台应用加一台数据库，有钱的用过硬负载，没钱的选择软负载；稍微先进点的应用再模块化,逻辑跨模块调用数据库不同实例 ，再先进点的话把模块化的东西在接口服务器实现 。但是这些都是重型或半重型的 ，改一个东西不是伤筋动骨 ，劳师兴众 ，涉及的应用都要更新一遍 ，有问题影响面涉及广 ，出现问题后 ，排查起来也是老大难的问题 ，太难了 。
能否精准打击，哪里需要更新哪里？
这个真的是可以的，按业务特定设置不同服务，公共部分抽取出来共享，设置相应的组织架构开发维护，对其负责。微服务要怎么落实？第一步架构选取，流行的是spring cloud，第二步学习理解框架原则优缺点，第三步结合自身业务和组织架构剪裁框架内容，第四部设计落地细节。从一个服务使用开始梳理强大的spring cloud提供的能力。
服务部署上去了，怎么去访问要知道每个服务地址端口，指定去访问？
成百上千个服务，这可是要消耗记忆带宽的活儿。因此就有了注册/发现、治理服务中心EUREKA,这可是阿基米德名言:找到了，这下好理解了吧。服务状态管理都需通过EUREKA，主动发起上线、下线请求，EUREKA通过定时的健康轮询治理发现的。能找到服务，我们需要自己去找吗？当然不需要了，机器能做的事情就交给机器了，由同一调度中心，服务网关来处理，同时起着负载作用。
部署工作是繁琐的，繁琐事情重复做，枯燥无味，同时问题并不能避免。因此有了配置中心config，可以同步配置中心的配置。配置过程中需要用到已有的能力，通过注释申明，沟通角度就是双向沟通，你要，你得说，要不我怎么知道你要呢。流行术语就是即插即用。快速部署还可以用到容器技术Doctor操作系统层次隔离，一键复制。
服务多了，怎么做到服务能力感知？业务出问题，问题在哪个点？
数量小日志能扒出来，多了或许说做日志聚合，但是还是不能直观反应出问题，首先是问题出现了，日志还是在时时刷，量大。第二问题现象是什么，跟问题反馈人相关方面能力有一定关系，说不定被带到沟里，爬出坑的时间花费不少。主要是问题稍瞬即逝，缺少目击者。要解决这个问题需要建立一个监控体系，对整个服务调用链路进行监控，张三调用李四，李四调用王麻子，谁慢谁快，谁有问题，一清二楚，显而易见。要达到这种效果需要设计服务调用标识，信息管理视角需要一个连接符，因此定义了Traceid,层级关系定义spanid，对于服务跟踪基本是能解决了。
微服务其实条条框框还是很多，包括要遵循的一些原则，REST使用，版本号，命名规范，CAP的取舍等等。
网友评论