关于微服务的思考和解决办法（一）

首先需要清晰概念，什么是微服务，为什么需要微服务？

微服务是一种思想，落到实际简单说就是将原来的工程应用拆分成不同的小应用，每个小应用都是一个相对独立的项目，可以独立的迭代启停并接受CURD等接口（REST或RMP或SSH）用于req和res。

微服务的好处，可以很好的解耦数据、产品、开发、基础设施等，使维护迭代大型应用变成可能，变成全异步和全并行，微服务实际也是一种解决方案，必然他也不是银弹；当然，凡事都有两面性，微服务也有很多不利或者坑，如果不有效解决就会造成很大的麻烦：盲人摸大象。

首先，目前很多公司现在的交付场景：

然后，再看看微服务下的交付场景：

两下一对比我想，好处坏处、利弊得失和动静的维度立刻就显现出来了：

1、工作流，一个总体串行局部串行的一个是总体分步分项局部串行与交叉并行的；

2、我个人微服务有9个比较重要的特征：服务组件化、按照业务组织team、开发与产品融合度提升（模块开发逻辑要准寻产品的演化逻辑）、智能端点和哑管道（服务调用的端点动态获取，加权与熔断）、去中心化（语言与框架的选择多样性）、数据管理去中心化、基础设施自动化、容错设计（网络是不可信的组件是不可信的，降级、灾备、伸缩势必智能且变成可行）、演进设计变成进化式设计

3、微服务的缺点：

3.1 大型项目系统拆分，技术成本高企，对技术人员的要求也会提高很多

3.2 更清晰的服务边界也使得标准化变得困难，微服务非常依赖上层框架来进行规约，否则迭代的时间成本、断服成本和协调成本变得很高

3.3 大个单体应用内部通讯成本远低于微服务组件通信成本

3.4 DB的设计与业务规划变成难点和痛点

3.5 多组件有效健康管理是头等要务，全链路监控、报警、调度、审计就变的非常有挑战性

。。。。待续