微服务架构拆分

微服务架构拆分
2014年Martin Fowler与James Lewis对一种新的架构风格-微服务-提供了完整的定义
微服务的基本构成要素：
1每个服务运行在自己的进程中；
2微服务之间采用轻量级通信；
3微服务应基于业务能力进行构建；
4采用自动化部署机制实现微服务的独立部署；
5服务的管理应采用最小的中心化管理。

微服务架构拆分和落地

微服务架构1.0-中心化（统一语言和数据库等，落地简单）
每层可以用不同的语言和工具完成
多语言，通信设施边复杂，落地难
1.0微服务统一语言，统一基础工具，避免重复造轮子。

如今微服务已经进入所谓的Service Mesh 2.0时代，诸多微服务框架、平台以及设计原则如雨后春笋般出现。
微服务架构2.0-去心化（最小中心化管理”，服务网格（Service Mesh）
即采用微服务时，将不再受限于服务实现的技术栈，无论是开发语言还是数据库，都可以自由选择
Service Mesh形成了一个分布式的互连代理网络，
服务对于代理无感知，且服务间所有通信都由代理进行路由
Service Mesh是“时间的产物”，Docker、Kubernetes等容器技术
直接推进了对于Service Mesh的需求，让复杂的系统可以被轻松部署和管理
未来Service Mesh将如何发展还未可知，或许会像TCP/IP一样形成标准，

微服务1.0服务拆分：
soa只做了垂直拆分，拆分后还是一个单体应用。
微服务按照2个维度拆分，垂直和水平，拆分更加彻底

第一次垂直拆分：按照业务架构 或组织架构（按照部门职能拆分），
                            不仅仅是业务架构，也是组织架构。
某机票预定网
会员服务
机票查询
订单查询
短信服务
机票支付
机票值机

第二次水平方向拆分：api粒度拆分，全部rpc接口调用
订单查询 pp手机页面 
订单查询 网关，鉴权，限流，协议转换
订单查询 业务逻辑层，1调用价格接口，2调用票数接口，组装信息
订单查询 订单查询数据访问基础层，价格接口，剩余票数接口
订单查询 数据DB

二期后续，量大了，可对每个微服务在做直拆分和水平拆分，
前期，一个系统可以2到3个人维护3个微服务，拆分10到20个微服务，
后期，更具业务增加适当拆分30到50个微服务。

微服务2.0(技术难度高，大型互联公司)
2016年9月Linkerd第一次公开使用之后，伴随着Linkerd、Envoy、Istio、NGINX Application Platform、Conduit等新框架的涌现，
服务网格和它的边车（Sidecar）模式让多语言的微服务协作变得更加容易。未来几年的微服务发展，应该是服务网格占据主流。

整体来看，微服务的技术实践已经开始向更加成熟迈进。在微服务的实践与运用上，互联网企业走在了前面，它们甚至在诸多方面都成为了微服务技术发展的先行者。
然而，对于微服务的设计、技术落地以及相应的文化建设和基础设施搭建，许多团队的能力与意识仍显不足，尤其是针对一些传统企业，要实现企业架构向微服务转型，
依旧是“路漫漫其修远兮”。James Lewis与Martin Fowler两位大师对微服务的定义依旧具有蓬勃的生命力。因此，许多正在或者计划实践微服务的架构师们，
还需要深入理解这一定义，结合实践找到符合自己企业和团队的微服务演进之路