内容摘要：以前学习软件工程的时候，书上说代码要“高内聚、低耦合”，曾经看过Numpy的代码，其规范程度和接口设计确实让人佩服。前面讲过DevOps,Docker, CI/CD这些技术概念。这个时代确实发展太快，新名词每天都会出现，回头想想学会这些技术后，我们怎么改进以前的软件设计呢？今天想说的就是基于Rest的微服务架构软件设计。
1、什么是微服务？
微服务是相对于传统的紧耦合软件架构而言，近年来随着云基础设施建设，虚拟机和容器编排技术不断发展，而产生的一种新的软件架构形式。
微服务倡导的就是功能之间尽量解耦，特别适合于多个小规模团队之间的协同。大家只需要知道接口，通过标准的协议形式就可以实现交互，对于怎么内部怎么实现？对于服务使用者并不关心。
微服务架构中，每个服务都运行于自己独立资源环境中，可以通过精简配置，达到最大化利用系统资源的目的，如图1所示。
记得很久以前，一位管理大型国企计算资源的朋友问我，他说：“你知道怎么管理服务器机群最可靠吗？”，要知道十几年前，有一台服务器跑点服务，那是挺奢侈的事情。我当时想那肯定是尽量多的装软件，再把反病毒各种安全软件多装几个啊！但是他告诉我，一台服务器尽量跑一个服务就行了（他服务器上是重来不装杀毒软件的）。他的解释是：因为这样稳定，服务器上软件装的越多，就越容易出错。什么FTP服务，Web服务，邮箱服务，统统都放到一个服务器，一旦出问题全完蛋。
我理解这就是微服务思想的起源。那时候也有vmware这种虚拟机，但是这几年云平台普及后，网络速度越来越快，各种容器环境获取更加方便，我认为这时候微服务架构流行恰逢其时。
PS：现在的各种机器学习算法、模型层出不穷，绝大多数用户没时间去验证你核心模块多先进，原创算法有多少，如果你是做图像识别，拿起手机照一张照片，本来是一只猫，结果识别是一个老虎，哪基本就不会有以后了...
2、Restful的API好处有那些
了解微服务之后，我们要问微服务必须要满足什么条件？微服务接口之间的信息传递靠什么协议实现？
Sam Newman 的著作《微服务设计》中指出，微服务设计需要遵循：
- 标准的 REST 风格接口（基于 HTTP 和 JSON 格式）
- 独立部署，避免共享数据库（避免因为数据库而影响整个分布式系统）
- 业务上的高内聚，减少依赖（从设计上要避免服务过大或者太小）
REST风格啥意思？
REST英文是Representational State Transfer，实际上是一种软件架构风格。在REST体系中，通过url来设计系统，每个url都代表一个resource，而整个系统就是由这些resource组成的。因此，如果url是设计良好的，那么系统的结构就也应该是设计良好的。
REST风格的功能设计，通过url定位资源（就是一个浏览器中用的地址），用HTTP动词（GET,POST,DELETE,DETC）描述操作，用户使用这些操作就可以看作是API接口调用。
一般接口的返回值是JSON字符串（就是一组用大括号描述的字段和数值集合）。
用HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误，403表示Bad Request等。
那这种风格的接口有什么好处呢？前后端分离。前端拿到数据只负责展示和渲染，不对数据做任何处理。后端处理数据并以JSON格式传输出去，定义这样一套统一的接口，你完全不用考虑用户使用什么系统，无论在web，ios，android三端都可以用相同的API接口，是不是牛掰？！
3、什么场景下适合采用微服务
简单来讲，就是业务发展越来越大，队伍不好带的时候，哪只能拆分了，管理者不关心细节实现，将系统设计分成：前台、后台（现在还有中台的概念），前者用于处理页面渲染，用户请求；后者这是处理业务逻辑的实现。
还有一种情况就是需求经常需要变更，这时候耦合在一起的软件体系，牵一发而动全身，我见过一些复杂软件，管理员的说法是真不敢动啊，出错了算谁的责任。对于微服务架构的软件系统，每个API接口的更新，都是分布式的，不同的版本有不同的接口文档，即使出问题也是局部性的，不会影响整个系统运行。
哪回过头来，那些系统不适合微服务呢？简单来讲，对于一些需求很稳定的系统不需要变更。还有就是对性能要求比较高的，比如股票软件。
一句话结语：个人认为科研产品和技术，由于功能的升级和发展经常是不断变更的，了解点新技术别让自己落伍，越早越好！！！
