大家好，欢迎来到Tlog4J课堂，我是Jensen。你可能会好奇——架构师关注的重点是什么？通常适用的“术语”是什么？在这里，我整理了一个架构师的技术语言。希望大家看完后能够逆向推演建筑师。需要注意的重点。掌握了这些技术语言后，我们就可以将其作为技术交流中强有力的理论支撑基础。架构技术思考与衡量指标1、ROIROI一般指投资回报率，投资回报率=年利润或年均利润/总投资×100%，比如你投资100元，获利10000元，那么ROI就是10000/100*100%=10000%，如果ROI小于100%，说明投入100元，利润不到100元。每个人都知道这是一笔糟糕的交易。此外，投资回报率可以作为企业生产的一项基本指标。我们可以把ROI理解为投入产出比——做任何决定之前，先考虑是否值得去做。我们可以用经验去预测或者用数据分析得出前人告诉我们的结论：在错误的方向努力，只会让你失去更多，所以为什么说选择比努力更重要，就是这个道理。比如，一个简单的客服系统，如果花一个月的时间去优化，只是为了让客服体验更好，但对客户留存和交易转化没有任何影响，也没有大幅度提高客服效率，那么就是不值得做这个，ROI不到1，价值点不高。当然，ROI指标的缺点是缺乏全局概念，因为我们还需要考虑投资的隐性回报。比如市场部在一次营销活动中投放CPS信息流，投入总成本10万元，获得总利润10万元RMB10,000，获得10,000个客户，单从金钱成本上来说是不划算的，但是这个营销活动相当于免费获得了10000个客户，而且这些客户可以在商城进行二次交易，所以总体来看，总的ROI大于100%。在架构方面，ROI常被用来判断技术决策、项目决策等现阶段是否值得投入人力和时间成本。2、SOLIDSOLID原则包括以下五项：1、单一职责原则（SRP）表示一个类只有一个职责。一个类就像一个容器，它可以添加任意数量的属性、方法等。2.开闭原则（OCP）一个类应该对扩展开放，对修改关闭。这意味着一旦类被创建并且应用程序的其他部分开始使用它，它就不应该被修改。简单来说：当别人要修改软件功能时，他不能修改我们原来的代码，只能添加新的代码来达到修改软件功能的目的。3、根据里氏代换原则（LSP）派生出的子类应该能够替代基类，也就是说，基类可以出现的地方，子类就必须出现。值得注意的是，在通过继承实现多态行为时，如果派生类不遵守LSP，可能会导致系统抛出异常。4.接口隔离原则（InterfaceSegregationPrinciple，ISP）指出类不应该被强制依赖于它们不使用的方法，也就是说一个接口应该有尽可能少的行为，它是流线型的和单一的。5.依赖倒置原则（DIP）指出高层模块不应该依赖低层模块，相反，它们应该依赖抽象类或接口。这意味着高级模块中不应使用具体的低级模块。我们来看看它们之间的关系：单一职责是所有设计原则的基础，开闭原则是设计的最终目标。里氏替换原则强调子类替换父类后程序运行时的正确性，用于帮助实现开闭原则。接口隔离原则在帮助实现里氏替换原则的同时，也体现了单一职责。依赖倒置原则是过程式编程和面向对象编程的分水岭，也被用来指导接口隔离原则。简单来说，依赖倒置原则就是告诉我们要对接口编程；当我们对接口编程时，接口隔离原则和单一职责原则告诉我们要注意职责划分，不要把所有东西都塞在一起；当我们的职责都差不多的时候，里氏代换原则告诉我们，在使用继承的时候，一定要注意遵守父类的约定；而上面提到的四项原则，他们的最终目的都是为了实现开闭原则。3.拆分/解耦思路拆分常用来描述组织拆分、业务拆分、数据拆分、服务拆分等，拆分依据和拆分粒度是我们需要关注的重点，也就是说——为什么你是这样拆的吗？怎样的拆解才是合理的？“在一起不是很好吗？为什么要拆？拆了之后问题会很多，整体的复杂度也会变高！”说的挺有道理的，但是如果我们从整体上考虑，就可能变得不合理了。下面我们从团队、产品、交付、技术、业务等方面来分析系统拆分的需求：1.组织架构从最初的一个团队逐渐转变为拆分成多个团队。团队根据不同的业务线进行划分。为了减少由于各个业务系统和代码之间的关联和耦合，不再可能由多个团队共同向一个代码库提交代码。必须拆分原有系统，以减少团队之间的干扰。2.安全这里所说的安全不是系统级的安全，而是代码或者结果的安全，尤其是很多有核心算法的系统，为了不泄露代码，需要对相关系统进行模块化，隔离核心功能和保护知识产权。3、替代为了提供差异化??服务，一些产品需要具有可定制的功能，可以根据用户的选择自由组合成一个完整的系统。比如有些模块，免费用户使用的功能和付费用户使用的功能肯定是不一样的。同样要求这些模块是可替换的，判断免费用户还是付费用户是用不同的模块组装的，这也需要对系统进行模块化拆分。4.交付速度单一方案最大的问题是系统错综复杂，牵一发而动全身。或许一个小小的改动就会导致很多功能无法正常工作，从而大大降低了软件的交付速度，因为每一次改动都需要进行大量的回归测试来保证每个模块都能正常工作，因为我们不知道是什么变化会影响，所以需要做很多重复性的工作，增加了测试的成本。这时候就需要对系统进行拆分，梳理各个功能关系并解耦。5.技术要求1）由于技术栈固定，特别是比较大的系统，单体应用不能轻易升级，或者对新技术或框架的引入封闭，而且每种语言都有自己的特点，单个程序不能享受其他语言带来的便利，对应团队，团队技术相对单一。2）与基于业务的纵向拆分相比，基于技术的横向拆分也很重要。使用数据访问层可以很好的隐藏对数据库的直接访问，减少数据库连接数，提高数据使用效率等；水平拆分Points可以大大提高各级模块的可重用性。6.业务需求由于一些特殊的业务需求，比如对某个功能或模块的高可用、高性能、可扩展性需求，虽然也可以将单体整体部署在分布式环境中，以实现高可用，高性能等，但是从系统维护的角度来看，每次变化都要重新部署所有节点，这显然会增加很多潜在的风险和不确定性，所以有时候我们不得不选择那些有特殊需求的功能进行抽象系统，独立部署和扩展。在更大的范围内，拆分可以分为垂直和水平两种类型。垂直拆分主要是从业务角度进行，按照业务划分为不同的子系统；而横向拆分则侧重于技术的分层，每个层级的技术侧重点不同，可以充分发挥和培养团队中每个人的技术特长。4、孤立思维我们再来说说孤立思维。我们在做技术的时候一定要有孤立的思维，不要把多个东西混为一谈，这样才能聚焦重点。隔离设置源自船舶的设计。在船舶设计中，我们经常会设计多个舱室，每个舱室都是一个独立的空间。这样，船舶在行驶过程中，即使有一个舱室破损进水，也有舱室可以正常工作，才不会整艘船沉没。每个架构师、程序员、运维工程师都必须了解隔离设计。在分布式系统中，隔离设计有两种不同的实现方式，一种是系统隔离，一种是用户隔离。1、系统隔离在分布式系统中，我们经常会把不同的模块部署到不同的机器上，以防止不同的模块相互影响（每台电脑的资源都是有限的，尤其是IO密集型，CPU密集型模块很容易拖累其他业务).此外，我们还需要将底层存储与上层访问层分开。在实际应用中，我们通常会针对不同业务的不同存储进行数据库拆分，而在接入层，为了节省成本，往往会采用限流设计。2.另外一种隔离用户的方式就是我们经常会以用户为单位进行隔离，不同的用户访问不同的运行实例。这在大型互联网公司中也很常见。比如阿里巴巴有北京、上海、杭州、深圳等，在不同的数据中心，不同的用户访问不同的系统实例。不同的用户组访问不同的实例组，可以让隔离更加彻底，但是也伴随着非常大的挑战。比如我们会面临不同实例之间的存储、通信等各种问题。隔离的底层逻辑映射到计算机系统层面，就是隔离CPU、内存、网络、IO或存储层面，避免计算机资源相互干扰。在我们日常的技术交流中，我们通过隔离来判断业务、系统、代码是否会相互影响，系统的边界是否清晰，最终让我们实现的系统更加稳定。5.ACIDACID是指事务的四个特性，即Atomicity、Consistency、Isolation和Durability，简称为事务的ACID特性，狭义的ACID指的是数据库事务的ACID。1.原子性（Atomicity）一个事务必须被看作是一个不可分割的最小工作单元。整个事务中的所有操作要么提交成功，要么失败后回滚。不可能停滞在中间的某个环节。对于一个事务来说，不可能只执行其中的一部分。2.一致性（Consistency）数据库总是从一种一致状态过渡到另一种一致状态。3.隔离性一般来说，一个事务所做的修改在最终提交之前对其他事务是不可见的（在并发环境下，并发事务之间是相互隔离的，事务之间不会相互干扰），隔离可以防止数据多个事务并发执行时交叉执行造成的不一致。针对不同的业务需求，隔离分为四个级别：读未提交、读已提交、可重复读、序列化。这四个层次的隔离度依次增强。事务隔离级别越高，越能保证数据的完整性和一致性，但同时对并发性能的影响也越大。4.持久性一般来说，事务一旦提交，其修改将永久保存到数据库中，即使系统崩溃，修改的数据也不会丢失。在我们实际应用中，可以利用数据库事务的ACID特性来满足实际的业务场景，所以我们在做技术的时候一定要牢记ACID，随时调用。六、CAP、BASE有一句话不知道大家听过没有，叫做“CAP走向世界”，为什么CAP如此重要？这里先科普一下：CAP定理表达了分布式系统的三大特性：一致性（Consistency）、可用性（Availability）和分区容忍度（Partitiontolerance），三者之间形成不可能三角，即强一致性、高可用性和分区容错性在分布式系统中不能同时满足。CAP定理CAP定理指导我们在分布式架构中，系统应该如何在CP和AP之间进行权衡，因为分布式系统是分区的，首先要满足分区的容错性。比如常用的分布式配置中心和服务注册中心，我们允许系统之间存在短期的数据不一致，同时也要保证系统的高可用，以免影响系统的正常运行，所以这个分布式系统可以useAP+finalconsistency对于涉及交易场景的业务，比如银行转账等交易场景，采用CP的方式设计更加严谨。CP系统不能保证高可用吗？当然不是。我们还有其他实现可用性的方法，比如在CP之上嵌套AP系统，负责CP系统的高可用。在大型分布式系统中，CP+AP是结合使用的。那么什么是基础？BASE理论是BasiclyAvailable（基本可用）、SoftState（软状态）和EventuallyConsistent（最终一致性）这三个词组的缩写，是CAP定理中一致性和可用性权衡的结果，即源于对大型互联网分布式系统实践的总结。BASE理论的底层逻辑是：通过基本可用性和软状态来牺牲CAP中的可用性，通过最终一致性来牺牲CAP中的强一致性。BASE是在CAP的基础上逐步演进的：即使不能实现强一致性，应用也可以采用合适的方式实现最终一致性。CAP中提到的一致性是强一致性。所谓“牺牲一致性”是指牺牲强一致性来保证弱一致性。7、分布式事务随着架构的演进，系统和数据库已经不同程度的拆分，系统之间的通信也从进程内通信变成了网络IO通信。相应的，事务的ACID也分散到各个单体应用中，无法再服务于有ACID需求的业务场景。这时候就需要一个能够满足ACID特性的分布式事务解决方案来解决业务场景。怎么办，数据库的ACID是在进程中通信的，因为在单体应用中，这很容易做到，在分布式系统中也可以实现类似的设计，不同的是通信方式从in-进程通信变成了网络IO通信，前人也提出了一些分布式事务的方案。我们把事务的范围提升到分布式系统的“上帝视角”，那么单个事务就变成了全局事务。以下是X/Open组织提出的DTP模型：DTP模型在DTP分布式事务模型中，XA除了规范定义的RM-TM交互接口，即TM与数据库的接口规范，TM也用它来通知数据库事务开始、结束、提交、回滚等；XA接口函数由数据库厂商提供。分布式通信协议XA规范：第一步：AP在RM1和RM2之间创建JDBC连接。第二步：AP通知生成全局事务ID，将RM1和RM2注册到全局事务ID中。第三步：执行两阶段协议中的第一阶段准备。第四步：根据第一阶段的prepare情况，决定整体commit或rollback。XA规范中大致分为两部分：事务管理器和本地资源管理器。其中，本地资源管理器往往由数据库来实现。例如Oracle、DB2等商业数据库都实现了XA接口，事务管理器作为全局调度器，负责本地各种资源的提交和回滚。基于XA规范实现了两阶段提交（2PC）和三阶段提交（3PC）。另外还有TCC协议，也能满足我们实际的业务场景。8.系统容量估算系统容量是指系统能够承受的最大访问量，系统容量估算是系统架构师在流量高峰到来之前给出的一些技术指标值。是建筑师必备的技能之一。常用的技术指标包括：QPS、PV、UV、并发、带宽、CPU使用率、内存和硬盘使用率等。QPS（QueryPerSecond）表示每秒的查询量。在分布式系统中，QPS的定义是每秒单个进程请求服务器成功的次数。QPS一般可以通过压测工具来衡量，比如LoadRunner、ApacheJMeter、NeoLoad、http_load等。QPS=总请求数/总进程数/请求时间=总请求数/（总进程数*请求时间）站点访问来自一定时间范围内，同一个IP多次访问一个站点只算一次，一般是24小时。PV（PageView）是指页面访问次数，是指一定时间内页面被打开或刷新的次数，通常以24小时为单位计算。并发和带宽是否有可量化的公式？答案是肯定的。1.带宽计算平均带宽的计算公式为：平均带宽=总流量（比特）/这些流量持续时间（秒）=（PV*平均页面大小*8）/统计时间（秒）公式中的8指的是最重要的是将Byte转换为bit，即8b/B，因为带宽的单位是bps（比特率），即bitpersecond，每秒位数，容量单位一般使用字节。假设一个站点日均PV为10w，平均页面大小为0.4M，那么其平均带宽需求为：平均带宽=（10w*0.4M*8）/（60*60*24）=3.7Mbps上面的计算只是平均带宽，我们在预估容量的时候需要峰值带宽，也就是要保证网站在流量高峰期能正常运行。假设峰值流量是平均流量的5倍，这5倍称为峰值因子。据此计算，实际需要的带宽约为3.7Mbps*5=18.5Mbps。带宽需求=平均带宽*峰值系数2.并发计算并发也称为并发连接数，一般是指单台服务器每秒处理的连接数。平均并发连接数计算公式为：平均并发连接数=（站点PV*页面平均派生连接数）/（统计时间*网站服务器数量）页面平均派生连接数指一次页面请求产生的http连接数，比如静态资源的css、js、images等的请求数，这个值需要根据实际情况确定。比如一个由5台web主机组成的集群，其日均PV为50w，每个页面平均有30个派生连接，则平均并发数为：平均并发数=（50w*30）/（60*60*24*5)=35如果峰值因子为6，则峰值并发数为：峰值并发数=平均并发数*峰值因子=35*6=2103，预估服务器量是根据获取的日均PV与往年同期相比，可以根据并发量、页面衍生连接数、公司业务扩张带来的流量增长率计算服务器预估值。服务器预估值=站点每秒处理的连接总数/单机并发连接数=（PV*页面衍生连接数*（1+增长率））/统计时间/单机并发连接数注：统计时间，即PV统计时间一般为一天。写在最后，本文简单梳理了一些常用的架构师术语，不深入讨论。只是为了打开大家的技术眼界。短短的篇幅不足以了解技术的全貌。
