服务架构设计及其应用
一、SOA原则及概念
SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。SOA 并不是一个新鲜事物，而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排除使用 OOD 来构建单个服务，但是其整体设计却是面向服务的。由于 SOA 考虑到了系统内的对象，所以虽然SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。SOA是一种企业架构，因此，它是从企业的需求开始的。但是，SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个业务敏捷的架构意味着创建这样一个IT架构，它可以满足当前还未知的业务需求。所以第一点SOA的边界是十分明确的；第二服务间是自治的；第三服务间共享结构和协议，而不是类（class）；第四服务的兼容性依赖于策略。
二、SOA优点
其次，那我们为什么要使用SOA？SOA有什么优点？SOA其最大的特点就是①：互操作性，系统间的连接不需要额外的桥梁。②：版本控制，更新，升级，添加新功能不需要现有的客户端或服务端做停机处理③：灵活性，增强服务只需要升级硬件，而不需要调整软件。
由上图可以看出SOA的两边结构虽不同，且物理隔绝，但也阻止不了其互操作。因为SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。SOA工作的场景，更象是一个活的生物体，而不是象传统所说的“盖一栋房子”。IT环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求崭新的思维方式。如下文所写的，SOA的基础还是一些类似的架构准则。
三、SOA设计
由于本人参加的实际项目太少，这里采用之前看过的美团开发团队的SOA案例进行分析。美团开发团队在2015年初的订单系统，和团购其它系统如商品信息、促销活动、商家结算等强耦合在一起，约50多个研发同时在同一个代码库上开发，按不同业务结点全量部署，代码可以互相修改，有冲突在所难免。同时，对于订单系统而言，有很多问题，架构方面不够合理清晰，存储方面问题不少，单点较多，数据库连接使用不合理，连接打满频发等等。所以针对这些问题
他们按紧迫性，由易到难，分步骤地从存储、传输、架构方面对订单系统进行了优化。
系统使用一张表的自增来得到订单号，所有的订单生成必须先在这里insert一条数据，得到订单号。分库后，库的数量变多，相应的故障次数变多，但由于单点的存在，故障影响范围并未相应的减少，使得全年downtime上升，可用性下降。针对ID分配单点问题，考虑到数据库表分配性能的不足，调研了Tair、Redis、Snowflake等ID分配器，同时也考虑过将ID区间分段，多点分配。但最后没有使用这些方案，主要原因是ID分配对系统而言是强依赖服务，在分布式系统中，增加这样一个服务，整体可用性必然下降。 他们还是从数据库入手，进行改良，方案如下。如下图，由原来一个表分配改为100张表同时分配，业务逻辑上根据不同的表名执行一个简单的运算得到最终的订单号。
ID与用户绑定：对订单系统而言，每个用户有一个唯一的userid，我们可以根据这个userid的末2位去对应的id_x表取订单号，例如userid为10086的用户去id_86表取到值为42，那订单号就42*100+86=4286。通过看上面的技巧，我们发现订单根据“userid取模”分表和根据“订单号取模”来分表结果是一样的，因为后两位数一样。到此，分库操作就相当简单容易了，极限情况下分成100个库，每个库两个表。同一个用户的请求一定在同一个库完成操作，达到了完全拆分。
四、总结
从订单编号一个系统子模块来看，他们的团队针对服务的优化是非常厉害的设计上有整体的、长远的、合理的规划，分步骤朝这个方向靠拢。
二且对于整体系统来说，要找到瓶颈点整体优化。局部服务能力的提升并不代表整个系统能力的提升。
每一步操作应该有个评判的标准。优化前和优化后系统的可用性是提升了还是下降了，理论上是可以分析的。
整个服务已进行了拆分，变成一个个微服务，那就应该允许服务之间的差异化、个性化。避免大而统一且繁琐的配置。
这些经验都是值得我们去学习的方面，希望本人可以在以后的实际项目中运用到。
参考博客:https://zhuanlan.zhihu.com/p/24805442