认知故事
在聊微服务和服务网格架构之前，想聊一下自己之前愚蠢的认知。我的上一家公司之前的开发框架是自研的，总体上来说就是用XML自定义了一套编程语言规则，最后通过规则引擎翻译成Java语言实现业务逻辑、进程通信、服务等。架构图大致如下：
先对这个架构图有个印象，我们先聊完微服务和服务网格架构的演化回头再来看。
微服务架构
Service Mesh
架构演进时间表
微服务架构
其实微服务架构没有一个完全准确的概念，只要你服务的粒度拆分的足够细通常都可以说是微服务。所以一般我们认为微服务架构就是业务垂直拆分+水平拆分。
本质
二个维度的拆分
业务垂直拆分和水平拆分谁难?
水平拆分就是按代码功能拆就完事
业务垂直拆分涉及到业务架构的取舍了，例如登录服务是否要登进和登出
业务架构
组织架构
职能
产品部门、开发部门、运营部门等
业务
金融事业部、缴费事业部等
kpi不一致的问题
适用场景
需求层面
管理系统、erp系统
变化慢就不适合
性能层面
吞吐量(是否有必要作为要不要使用微服务架构的考量指标？)
RT(平均响应延时)
证券量化交易、高频交易不适合
数据一致性层面
事务最终一致性
目的
项目快速迭代
项目持续交付
最通用的微服务框架
微服务不是银弹
业务关注服务间“通信”
业务迭代速度变慢
最起码也是通过jar包引用的方式
基础设施组件升级困难
影响基础设施团队的交付能力和交付速度
基础设施团队要升级框架，业务开发同事说没空理你
多编程语言之间"通信"问题
业务每种语言一套基础设施，成本大
微服务架构演进
服务网格架构
既然微服务架构还是会存在很多问题，那么怎么去解决了，这个时候就出现了服务网格架构，架构图如下:
Service Mesh设计与实践
Service Mesh优点
Service Mesh独立进程、独立升级
业务团队专注于业务逻辑本身
一套基础设施支持多语言开发
业务团队和基础设施团队物理解耦
开源的Service Mesh
Istio
An open platform to connect, manage, and secure microservices
来自Google，IBM,，Lyft公司
Go语言/C++语言
Service Mesh集大成者
2017年05月10日 0.1.0发布
2018年06月01日 0.8.0b版本发布
2018年07月31日 1.0.0版本发布
Istio总体架构
Istio服务网络逻辑上分为数据面板(执行者)和控制面板(指挥者)
数据面板由一组智能代理(Envoy)组成，代理部署为sidecar，调解和控制微服务之间的所有网络通信
控制面板负责管理和配置代理来路由流量，以及在运行时执行策略
最通用的服务网格架构
所以，这个时候再回头看上家公司的架构，是不是跟服务网格架构的设计理念很相似呢？当年我还抱怨过这个架构很辣鸡，惭愧，当然他们现在拥抱了开源，目前还在面向服务架构阶段，但是我相信他们也会一步一步演进，又是一个轮回。最后，架构并没有优劣之分，最合适的即最好的。
